From: SourceForge.net <no...@so...> - 2012-09-28 12:56:59
|
Bugs item #3572727, was opened at 2012-09-28 04:24 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3572727&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 17. Commands I-L Group: development: 8.6b3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ashok P. Nadkarni (apnadkarni) Assigned to: Donal K. Fellows (dkf) Summary: lsort -integer does not like 64-bit ints Initial Comment: % 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. ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2012-09-28 05:56 Message: 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). ---------------------------------------------------------------------- Comment By: Peter Spjuth (pspjuth) Date: 2012-09-28 05:44 Message: Note that bug 218988 was about handling 64 bit integers on 64 bit compiles. I do agree that lsort -integer should handle bignums transparently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3572727&group_id=10894 |