[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Nasty NSString bug (garbage buffers)
From: |
Ondřej Hošek |
Subject: |
Re: Nasty NSString bug (garbage buffers) |
Date: |
Sat, 3 Mar 2012 20:44:53 +0100 |
(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