WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
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).
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?
> Discuss-gnustep mailing list
> Discuss-gnustep@... > https://lists.gnu.org/mailman/listinfo/discuss-gnustep