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 > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my Apple II _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
