John Cowan scripsit: > The bug is still present in 4.1.1, and it's drastic: > > #;1> (abs 2147483648) > -2147483648 > #;2> (abs 2147483649) > 2147483647 > #;3> (abs 2147483650) > 2147483646 > #;4> (abs 4294967296) > 0
Oops, dropped the following: Almost certainly this is happening because the fixnum is being converted to a C int, which is only 32 bits even on 64-bit architectures, at least the ones we support (in the standard LP64 model, ints are 32-bit and only longs and pointers are 64-bit). A fixnum should always be converted to a C long, which will retain full 63-bit precision on 64-bit systems and still provide 31 bits on 32-bit systems. It wouldn't surprise me if there were a fair number of instances of this bug in various parts of Chicken's C code. A question that remains is what to do when calling an existing C routine that expects an int with a fixnum that is too big to fit in 32 bits. Just truncating the fixnum doesn't seem like a Good Thing. -- John Cowan [email protected] http://www.ccil.org/~cowan Most languages are dramatically underdescribed, and at least one is dramatically overdescribed. Still other languages are simultaneously overdescribed and underdescribed. Welsh pertains to the third category. --Alan King _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
