0x80000000 is -2147483648 if you cram it inside a signed 2-complement (normal) 32 bit integer.
According to Pike, this is not the case:
int x; x = 0x80000000;
(1) Result: 2147483648
Your analysis is flawed. Pike does not "cram it inside a signed 2-complement (normal) 32 bit integer", so it doesn't make any statement about that case at all.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-26 23:08: Subject: Re: 64 bit ints
On Wed, Feb 26, 2003 at 09:30:04PM +0100, Mirar @ Pike developers forum wrote:
0x80000000 is -2147483648 if you cram it inside a signed 2-complement (normal) 32 bit integer.
According to Pike, this is not the case:
int x; x = 0x80000000;
(1) Result: 2147483648
On one hand, I want to have flexibility (64 and more bit ints), on the other hand I don't want to lose performance (say, I've to make a lot of operations on IPv4 addresses).
Bignums are good enough (for my purposes), but I can't do something like:
Bignum a_bignum = 12345;
or:
a_bignum = an_int + another_int;
and expect this to work (there is no `=() in Pike, but that is another story).
Yes, I could compile Pike without autobignums, but... The above prevents me from doing this :)
/Al
/ Brevbäraren