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

[David Ayers]

Alexander Malmberg wrote:

> If the current semantics really are too difficult (or too out-of-line
> with developer expectations), we should try to find better semantics
> (and document and implement them). In other words, if we want the
> example to be correct, we should change the semantics so that it is
> correct, not just add hacks to the implementation.
>  
If I'm following it correctly, this discussion is about (re)defining the 
semantics of:
http://www.gnustep.org/resources/OpenStepSpec/FoundationKit/Classes/NSString.html

- (id)initWithCharactersNoCopy:(unichar *)chars length:(unsigned 
int)length freeWhenDone:(BOOL)flag

Initializes the receiver, a newly allocated NSString, to contain length 
characters from chars. This method doesn't stop at a null character. The 
receiver becomes the owner of chars; if flag is YES the receiver will 
free the memory when it no longer needs them, but if flag is NO it 
won't. Note that the NO case could be dangerous if used with memory that 
could be freed. The NO flag should be used only when the provided 
backing store is permanent.

in combination with:

http://developer.apple.com/documentation/ReleaseNotes/Cocoa/Foundation.html
NSString:
NSString's copy method will no longer simply retain the string if the 
string was created with the NoCopy:freeWhenDone: methods (such as 
initWithCharactersNoCopy:freeWhenDone:), passing NO for the 
"freeWhenDone" value. Instead it will make a true copy.

Well, my personal feeling is that the change is incorrect.  The example 
of initializing from the stack just doesn't qualify for the existing 
NoCopy: methods.  What should have been considered instead are new 
initWith*NoCopy:freeWhenDone:bufferIsTemporary: methods to create fast 
wrappers for temporary buffers like those which would do true copies.  
But in my opinion the price of initWith*NoCopy:freeWhenDone: to do true 
copies is just too high.

Objects returned by those methods only have limited validity though and 
their usage should be discouraged except for very limited circumstances.

Cheers,
David