Re: GSIMap

[David Chisnall]

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