On 10 Jun 2011, at 14:14, Richard Frith-Macdonald wrote: > > On 2 Jun 2011, at 10:40, David Chisnall wrote: > >> >> On 2 Jun 2011, at 06:28, Richard Frith-Macdonald wrote: >> >>> >>> On 1 Jun 2011, at 23:48, David Chisnall wrote: >>> >>>> >>>> This is actually wrong in retain / release mode (-retain is not guaranteed >>>> to return self), >>> >>> The guarantee is that it's specifically documented to do so in the protocol >>> .... see >>> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html >>> So any implementation of -retain which doesn't return self is faulty, and >>> the programmer really deserves any error they have introduced by >>> overriding/replacing the default one. >> >> My reading of that is that the requirement to return self is only a >> requirement for objects implementing their own reference counting. > > I guess that's a possible reading (though it certainly doesn't say that) ... > but hard to justify I think. The NSObject class adopts/conforms to the > NSObject protocol and Apple don't document an alternative behavior afaik, so > really it (and anything based on it) should do what the protocol says. It > seems to me that your reading assumes that documented behaviors are telling > you what to do when you override a method rather than telling you what a > method does which, while a possible point of view, is pretty much unique to > you I think. In my experience, whenever documentation is telling you what to > do when you override something, it makes a clear distinction between default > behavior and the overridden behavior. > >> The more formal description of -retain in the static analyser expects >> -retain to return an owning reference, but not necessarily to the same >> object as the receiver. > > I think you must have misread ... the clang static analyser agrees with me: > > c = [c retain]; > > produces the warning > > 'Assigned value is always the same as the existing value'
In that case, someone should tell Apple: as I said in the original post, this contract is not honoured by all of their classes. Both Apple, and LanguageKit's closure implementations return a different object in response to -retain if the block is allocated on the stack. If someone tries to store a block in a dictionary, then GNUstep's implementation will store a pointer to the on-stack version, Apple's implementation will store a pointer to the heap version. Both will send a -retain message. The Apple version will work as developers expect, the GNUstep version is susceptible to trivial return-to-libc attacks. So, while you may be right in theory, that doesn't alter the fact that this is dangerous practice and should not be used in real code. David -- Sent from my IBM 1620 _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
