32 bit Number Bug
Hi folks, there seems to be a bug in the 32bit release of 0.6 with numbers arch -arch i386 macirb --simple-prompt
0x44485250 # reality check => 1145590352 NSNumber.numberWithInt(0x44485250) # then see all 32 NSNumber are weird... => 71848528 NSNumber.numberWithFloat(0x44485250) => 1145590272.0 NSNumber.numberWithInt(1145590352) => 71848528 NSNumber.numberWithFloat(1145590352) => 1145590272.0
versus: arch -arch x86_64 macirb --simple-prompt
0x44485250 # reality check => 1145590352 NSNumber.numberWithInt(0x44485250) => 1145590352 NSNumber.numberWithFloat(0x44485250) => 1145590400.0 NSNumber.numberWithInt(1145590352) => 1145590352 NSNumber.numberWithFloat(1145590352.0) # this is weird again... => 1145590400.0
to look a bit further, the bug turning point seems to be here for the 32bit release:
NSNumber.numberWithInt(536870910) => 536870910 NSNumber.numberWithInt(536870911) => 536870911 NSNumber.numberWithInt(536870912) => -536870912 NSNumber.numberWithInt(536870913) => -536870911
and here in the 64 bit:
NSNumber.numberWithInt(2147483646) => 2147483646 NSNumber.numberWithInt(2147483647) => 2147483647 NSNumber.numberWithInt(2147483648) => -2147483648 NSNumber.numberWithInt(2147483649) => -2147483647
also an other detail: 32bit turning point:
536870911 / 16 => 33554431
64bit turning point:
2147483647 / 64 => 33554431
Is there a workaround for these conversion problem?
Bonjour Louis-Philippe, Could you open a ticket on the tracker for that? 32-bit mode is really not well tested at this point so it doesn't surprise me there are a few bugs around. Laurent On Jun 14, 2010, at 10:28 AM, Louis-Philippe wrote:
Hi folks,
there seems to be a bug in the 32bit release of 0.6 with numbers
arch -arch i386 macirb --simple-prompt
0x44485250 # reality check => 1145590352 NSNumber.numberWithInt(0x44485250) # then see all 32 NSNumber are weird... => 71848528 NSNumber.numberWithFloat(0x44485250) => 1145590272.0 NSNumber.numberWithInt(1145590352) => 71848528 NSNumber.numberWithFloat(1145590352) => 1145590272.0
versus:
arch -arch x86_64 macirb --simple-prompt
0x44485250 # reality check => 1145590352 NSNumber.numberWithInt(0x44485250) => 1145590352 NSNumber.numberWithFloat(0x44485250) => 1145590400.0 NSNumber.numberWithInt(1145590352) => 1145590352 NSNumber.numberWithFloat(1145590352.0) # this is weird again... => 1145590400.0
to look a bit further, the bug turning point seems to be here for the 32bit release:
NSNumber.numberWithInt(536870910) => 536870910 NSNumber.numberWithInt(536870911) => 536870911 NSNumber.numberWithInt(536870912) => -536870912 NSNumber.numberWithInt(536870913) => -536870911
and here in the 64 bit:
NSNumber.numberWithInt(2147483646) => 2147483646 NSNumber.numberWithInt(2147483647) => 2147483647 NSNumber.numberWithInt(2147483648) => -2147483648 NSNumber.numberWithInt(2147483649) => -2147483647
also an other detail:
32bit turning point:
536870911 / 16 => 33554431
64bit turning point:
2147483647 / 64 => 33554431
Is there a workaround for these conversion problem? _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
avec plaisir! I found the bug when trying to use a 32bit only API... other way I could I never found it since it runs in 64bit mode by default. 2010/6/14 Laurent Sansonetti <lsansonetti@apple.com>
Bonjour Louis-Philippe,
Could you open a ticket on the tracker for that?
32-bit mode is really not well tested at this point so it doesn't surprise me there are a few bugs around.
Laurent
On Jun 14, 2010, at 10:28 AM, Louis-Philippe wrote:
Hi folks,
there seems to be a bug in the 32bit release of 0.6 with numbers
arch -arch i386 macirb --simple-prompt
0x44485250 # reality check => 1145590352 NSNumber.numberWithInt(0x44485250) # then see all 32 NSNumber are weird... => 71848528 NSNumber.numberWithFloat(0x44485250) => 1145590272.0 NSNumber.numberWithInt(1145590352) => 71848528 NSNumber.numberWithFloat(1145590352) => 1145590272.0
versus:
arch -arch x86_64 macirb --simple-prompt
0x44485250 # reality check => 1145590352 NSNumber.numberWithInt(0x44485250) => 1145590352 NSNumber.numberWithFloat(0x44485250) => 1145590400.0 NSNumber.numberWithInt(1145590352) => 1145590352 NSNumber.numberWithFloat(1145590352.0) # this is weird again... => 1145590400.0
to look a bit further, the bug turning point seems to be here for the 32bit release:
NSNumber.numberWithInt(536870910) => 536870910 NSNumber.numberWithInt(536870911) => 536870911 NSNumber.numberWithInt(536870912) => -536870912 NSNumber.numberWithInt(536870913) => -536870911
and here in the 64 bit:
NSNumber.numberWithInt(2147483646) => 2147483646 NSNumber.numberWithInt(2147483647) => 2147483647 NSNumber.numberWithInt(2147483648) => -2147483648 NSNumber.numberWithInt(2147483649) => -2147483647
also an other detail:
32bit turning point:
536870911 / 16 => 33554431
64bit turning point:
2147483647 / 64 => 33554431
Is there a workaround for these conversion problem? _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (2)
-
Laurent Sansonetti
-
Louis-Philippe