Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#635 lsort -integer does not like 64-bit ints

open
8
2012-09-28
2012-09-28
No

% lsort -integer {0x1ffffffff 3 4}
integer value too large to represent

An old (2000) bug 218988 exists for this but is marked fixed and closed.

Happens on 8.6b3 and 8.5.11.

Discussion

  • Peter Spjuth
    Peter Spjuth
    2012-09-28

    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).

     
    • priority: 5 --> 8
     
  • Don Porter
    Don Porter
    2012-09-28

    This is not a bug but a feature request.

     
  • Don Porter
    Don Porter
    2012-09-28

    • labels: 105658 --> 17. Commands I-L
    • milestone: 3071254 -->
     
  • Don Porter
    Don Porter
    2012-09-28

    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.

     
  • Don Porter
    Don Porter
    2012-09-28

    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.