in reply to Re: Problem with a sort result
in thread Problem with a sort result

Nope, Sir. I do run it on a 64bit server (linux), and the Perl I use on it shows the following first line when using '-v':

This is perl 5, version 16, subversion 0 (v5.16.0) built for x86_64-linux-thread-multi

Also, I think that my "-" implementation should have been within the limits of the "sort" specifications (by the way, I don't know who I should contact about it, but it is somewhat sketchy. I mean, telling us we should provide a negative, null, or positive integer is all well and good, but telling us WHAT IT MEANS (like "a null value means that both elements have the same rank", and so on) would have been a huge improvement.

Anyway, yes, it now works correctly when using <=>, so I'm guessing that, despite the version being a 64b Perl, there is indeed a problem with the huge negative numbers I got (possibly some kind of negative overflow, or merely a bug where the function doesn't expect as much data, and "loses" important parts, like the first characters (including the sign). I really don't know.

Replies are listed 'Best First'.
Re^3: Problem with a sort result
by salva (Canon) on Jan 15, 2016 at 09:59 UTC
    Hey, there are actually 2 bugs on perl!!!

    The first is the one I described before where any number returned by the comparison subroutine is coerced into an IV, but then, there is a C function that just wraps that sub and which has a return type of I32, so the result is coerced again into a 32bit number.