gnustep-dev
[Top][All Lists]
Advanced

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

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


From: Alexander Malmberg
Subject: Re: [Gnustep-cvs] Minor fix for strings initialised with data they don't own ... consistent [...]
Date: Tue, 04 Nov 2003 13:30:47 +0100

Richard Frith-Macdonald wrote:
> On Monday, November 3, 2003, at 11:33 AM, Alexander Malmberg wrote:
[snip]
> 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.

But these classes would have the 'owns buffer'-flag set.

Depending on what semantics we want, this may or may not be equivalent
to the 'free'-flag, but I'm going to implement it using this flag for
now since it provides the most flexibility. If we need some other way of
telling whether a buffer should be freed or not, we could simply have
two concrete leaf classes for that (one for external buffers that should
be freed, one for external buffers that shouldn't be freed).

[snip]
> > 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 have them in my copy of OpenStep, eg.:

""
- (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.
""

See
http://www.gnustep.org/resources/OpenStepSpec/FoundationKit/Classes/NSString.html

> 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.

I don't think the documentation could be interpreted any other way.

> 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.
[snip example]

I can see why they would think so, but it is clearly incorrect code.

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

The cocoa docs seem to be consistent with the OpenStep spec. I wouldn't
call it an interpretation; more like fudging the implementation.
Although the example you gave would be less likely to crash, it would
still be incorrect and unsafe. I see no reason to miss opportunities to
optimize when we don't really gain anything.

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.

- Alexander Malmberg




reply via email to

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