Re: Nasty NSString bug (garbage buffers)

[Eric Wasylishen]

Hey,
No worries, Richard already fixed the bug. Here is the test case output with 
base r34875.

2012-03-03 15:32:56.247 StoreBrowser[1847] substr = 'HAZ'
2012-03-03 15:32:56.270 StoreBrowser[1847] substr = 'HAZ'

Eric

On 2012-03-03, at 12:44 PM, Ondřej Hošek wrote:

> (Whoops, hit "reply" instead of "reply all".)
> 
> On Sat, Mar 03, 2012 at 10:52:40AM -0800, Jens Alfke wrote:
>> I got a couple of off-list replies saying that this behavior is 
>> correct/intentional.
> 
> Which it can’t be. While it is obviously forbidden to modify the
> buffer once it has been passed to an NSString, for the sake of
> simulating the side-effects of deallocation, modification should be
> considered OK.
> 
> I assume you have already seen this bug in effect without manually
> modifying the buffer (the example of a buffer on the stack says a
> lot).
> 
>> Also, has anyone looked at what Apple’s open-source CFString implementation 
>> does?
> 
> I just checked. If a substring is created using
> CFStringCreateWithSubstring, the backing buffer is copied
> (__CFStringCreateImmutableFunnel3 is always called with noCopy set to
> false). Sounds like GNUstep assumes, at least in this case, that the
> original string (or at least its backing buffer) survives its
> descendants.
> 
> Unfortunately, the NSString/GSString/etc. class cluster (or should I
> say clusterf*ck?) currently resists all my attempts to understand it,
> so I doubt I can be of practical help (patch writing) here.
> 
> Cheers,
> ~~ Ondra
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep