Am 16.01.14 17:17, schrieb Niels Grewe:
Am 16.01.2014 um 16:54 schrieb Niels Grewe <[email protected]>:
Hi Mathias,
first of all: Thanks for your patches! Unfortunately, this one is not correct for
32bit systems. The reason is that NSInteger is pointer sized, so it’s a 32bit
quantity on 32bit platforms. On 32bit OS X/iOS, calling -scanInteger: with a string
representing a larger value (say „9223372036854775807“, aka LLONG_MAX), will give
you the maximum value an integer can hold, while your solution will just do some
implementation defined thing when casting the 64bit value to 32bits. (I think most
of the time, you just loose the higher bits, so for „9223372036854775807", you
might get -1 instead of 2147483647, which would the correct result given the Apple
implementation).
Actually, implementing a solution that doesn’t have this problem isn’t
difficult at all. We know the pointer size at compile time, so we can just
conditionally call either -scanInt: (on ILP32) or -scanLongLong: (on
LP64/LLP64) to populate the NSInteger correctly. This is now in trunk.
Cheers,
Niels
Excellent! Thank you very much for fixing my fix. :-)
I thought that it doesn't matter what kind of garbage you get when the
value is higher than the target integer variable can accept, but after
reading your reply I agree with you that consistency is valuable, even
in case of an error.
Regards,
Mathias
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
