Re: [Gnustep-cvs] Minor fix for strings initialised with data they don't own ... consistent [...]

[Richard Frith-Macdonald]

On Monday, November 3, 2003, at 11:33 AM, Alexander Malmberg wrote:
> > > Since the 'structure' parts' interest in the memory management can be
> > > summed up in a single simple "is my buffer guaranteed to be valid at
> > > least until I am released"-flag (equivalent to the current 
> > > 'free'-flag
> > > for the external buffer case), this will work out nicely and should 
> > > fix
> > > this and any other bugs caused by leaking non-owned buffers.
> >
> > That's not what the 'free' flag means.  The flag means 'should I free
> > my buffer' when I'm deallocated.
>
> True, but this doesn't really have anything to do with whether it's 
> safe
> to retain-instead-of-copy or not. Inline strings and substrings don't
> have any buffers to free, but it's always safe for them (trivially for
> inline strings; for substrings, if it wasn't safe, we shouldn't have
> made a substring of it in the first place).
>
> Thus, the structure layer needs a "do I own my buffer (directly or
> indirectly, eg. by retaining someone who does)"-flag. If, as the
> documentation implies, this always true, we don't need an actual flag,
> but making the optimizations conditional on the free flag would still 
> be
> wrong.

Yes ... I agreed that the structure is better ... using the flag avoids 
the
possible bug, but doesn't provide the optimisation for all classes as
sme of them don't need to deallocate memory, but are still safe to 
retain.

> > The data is *always* assumed to be
> > "guaranteed to be valid at least until I am released"
>
> Indeed, the OpenStep docs do say this.
>
> > The problem is that the existing code assumes that the buffer will be
> > valid
> > until the instance is deallocated (which is true within the gnustep
> > libraries,
> > but might not be true for code ported from MacOS-X).
> > In additions to changing copy behavior to cope with this, we also need
> > to
> > change creation of substrings so that we don't use the substring 
> > classes
> > for substrings of classes which don't own their buffers.
>
> The cocoa docs seem equivalent OpenStep. This does simplify things a
> bit. However, given this, I don't see what you're trying to fix. If the
> buffer is always owned by the string, I don't see how the "retain
> instead of copy"- or substring-optimizations could ever be unsafe for
> correct code. Do you have an example of (correct) code for which this
> isn't safe?

No but ... the initialisers which allow you to set 'free when done' are 
new
MacOS-X additions, not in OpenStep.  I assumed (and think that the
Apple also assumed) that setting 'NO' for this meant that the instance 
was
safe to use the memory it was given without copying it.

In the latest MacOS release notes, they say they changed the copy 
behavior
in this case to stop the simple retain happening ... I can only infer 
that the
reason they did this is because developers were interpreting the use of
the NO free when done initialisation as meaning that the memory given
to the instance only needed to persist until the instance was released 
by
the code which created it.
eg.
{
unichar buf[] = {...};
NSString *s = [[NSString alloc] initWithCharactersNoCopy: buf length: N 
freeWhenDone: NO];
//  Use s for something .. eg passing it as an argument to a method 
which copies it.
[s release];
}
// At this point the memory on the stack may be corrupted etc,

Anyway, basically I changed it for consistency with the MacOS-X 
documentation,
even though I don't like this interpretation.