[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSIMap
From: |
David Chisnall |
Subject: |
Re: GSIMap |
Date: |
Fri, 10 Jun 2011 14:23:08 +0100 |
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
- GSIMap, David Chisnall, 2011/06/01