Re: libobjc2 message-to-nil inconsistency

[David Chisnall]

Please update, this was fixed last week, although the old behaviour is still 
consistent with OS X (return results greater than the size of a pointer are 
undefined).

David

On 8 May 2012, at 18:53, Jens Alfke wrote:

> Hi all. I’m debugging some software I’m porting from Mac OS X / iOS to 
> GNUstep. Just spent an hour tracking down a problem that stems from a 
> difference in the return value of a message to nil. Specifically:
> 
>       NSNumber* n = nil;
>       SInt64 value = [n longLongValue];
>       assert(value == 0);    // passes with Apple’s runtime, fails with 
> libobjc2
> 
> In the olden days on OS X, this was a no-no because the return value of a 
> 64-bit message-send to nil was undefined (objc_msgsend was zeroing the return 
> value in a way that worked for 32-bits or less but not for 64-bit.) However, 
> at some point (10.6 I think) the dispatcher was improved to also zero the 
> 64-bit return state. My code implicitly depends on this behavior.
> 
> It appears that libobjc2 still has the old behavior and does not clear the 
> 64-bit return value (at least not in a 32-bit process.) So I’m getting 
> garbage values from -longLongValue and similar methods when the receiver is 
> nil, which breaks my code. Obviously I can put nil-checks in the code, but 
> I’m not sure where exactly all the places are that depend on this and need to 
> be changed. There could be a lot of debugging ahead.
> 
> Is this a known issue in libobjc2? Is it something that will be fixed, or is 
> it considered a difference in behavior that will remain that way?
> 
> —Jens
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


-- Sent from my Apple II