[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nasty NSString bug (garbage buffers)

From: Eric Wasylishen
Subject: Re: Nasty NSString bug (garbage buffers)
Date: Sat, 3 Mar 2012 15:34:23 -0700

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'


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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

reply via email to

[Prev in Thread] Current Thread [Next in Thread]