Agreed as well; IIRC, we're currently assuming that they fit in a 'long' and that's wrong these days (and this was probably just an oversight when bignum support was added).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Or, if you're on a 32-bit system, you may see it with
the value 0xffffffff.
Changing to unlimited integer support will have the advantage
of platform independence. The disadvantage will be to any non-portable
scripts relying on the ability to use hex of known size to specifiy negative
numbers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that bug 218988 was about handling 64 bit integers on 64 bit compiles.
I do agree that lsort -integer should handle bignums transparently.
Agreed as well; IIRC, we're currently assuming that they fit in a 'long' and that's wrong these days (and this was probably just an oversight when bignum support was added).
This is not a bug but a feature request.
The compatibility wrinkle that must be ironed out is this:
% lsort -integer {0xffffffffffffffff 1}
0xffffffffffffffff 1
Or, if you're on a 32-bit system, you may see it with
the value 0xffffffff.
Changing to unlimited integer support will have the advantage
of platform independence. The disadvantage will be to any non-portable
scripts relying on the ability to use hex of known size to specifiy negative
numbers.
And by the way, these were not matter of oversight.
I pleaded for engagement on completing the job before 8.5
went final. See TIP 297. And no one was interested.