http://qs321.pair.com?node_id=11107370


in reply to [XS] Weird behaviour on some Linux systems

sv_setpvf, which is implemented by Perl_sv_vcatpvfn_flags does not use sprintf directly. Some internal parts will be be handled by sprintf, but a lot of that depends on how perl is configured.

Assuming this you are not using a quadmath or longdouble build, %.19g is special cased to use SNPRINTF_G, which is a macro for Gconvert which is a macro determined at Configure time and can point to several different functions.

On my Ubuntu system, it is using gcvt: 

$ perl -V:d_Gconvert
d_Gconvert='gcvt((x),(n),(b))';

On my macOS system, it is using sprintf: 

$ perl -V:d_Gconvert
d_Gconvert='sprintf((b),"%.*g",(n),(x))';

The perlclib documentation explicitly says that perl functions tend not to use the standard library. While it documents how to do things "the Perl way", it doesn't say that the functions will behave identically.

I'm not entirely clear if this is a bug or not. The documentation for this is under sprintf in perlfunc. While this behavior would seem to be violating the spirit of specifying the width, it is technically within the maximum width being provided.

Replies are listed 'Best First'.
Re^2: [XS] Weird behaviour on some Linux systems
by syphilis (Archbishop) on Oct 12, 2019 at 12:48 UTC
    UPDATE: After I sent off this post it occurred to me that the issues Haarg had just explained were very likely the same issues that Corion had hinted at earlier ;-) 

    On my Ubuntu system, it is using sprintf: 
$ perl -V:d_Gconvert
d_Gconvert='gcvt((x),(n),(b))';

    [download]

    Yes - same for my Ubuntu system.
    That should mean that you should also find that the script I posted in my last post outputs: 
    1..1
not ok 1 - they are the same
#   Failed test 'they are the same'
#   at w.pl line 40.
#          got: '9.2233720368547758e+18'
#     expected: '9223372036854775808'
# Looks like you failed 1 test of 1.

    [download]
    The unexpected '9.2233720368547758e+18' arises because: 
    sv_setpvf(keysv, "%.19g", SvNV(arg));
is, in effect, converted to:
sv_setpvf(keysv, "%.17g", SvNV(arg));

    [download]
    Can we rely on this value of $Config{d_Gconvert} to reliably indicate that such behaviour will occur ? (If so, that would be most useful.)

    For my Windows 7 builds that avoid the problem, I'm finding that perl -V:d_Gconvert matches the output you're seeing on your macOS.

    For sane purposes on perl's whose nvsize is double, a width of 17 decimal digits is indeed sufficient.
    But when you're trying to (mis)use formatting of doubles in the way that List::Util::uniqnum() does, then you really do need a width of 19 decimal digits if ivsize is also 8.
    Otherwise, for example, uniqnum(1 << 60, 2 ** 60) won't detect that the 2 values are equal.

    About 6 hours ago I did submit a bug report about this to perlbug@perl.org but it hasn't yet been assigned a ticket number so I currently can't provide a link.
    It will be interesting to hear what p5p has to say.

    The perlclib documentation explicitly says that perl functions tend not to use the standard library. While it documents how to do things "the Perl way", it doesn't say that the functions will behave identically.

    I'm thinking that the perlclib docs could well make a point of stating that the functions might not behave identically - at least wrt sprintf vs sv_setpvf.

    Cheers,
    Rob
[reply]
[d/l]
[select]
      But when you're trying to (mis)use formatting of doubles in the way that List::Util::uniqnum() does, then you really do need a width of 19 decimal digits if ivsize is also 8.

      I certainly sympathize. I've been trying to solve the same problem in List::Util::PP, and so far have settled on using roughly pack('FJ', $_, $_). There are still some issues around the unsigned int upper boundary though.

      It should be possible to avoid the special case to use Gconvert by tweaking the format you use. I can get the full width output on my Ubuntu system by using '%0.19g': 

      $ perl -e'printf "%.19g\n", 2 ** 57'
1.4411518807585587e+17
$ perl -e'printf "%0.19g\n", 2 ** 57'
144115188075855872

[reply]
[d/l]
[select]
        I can get the full width output on my Ubuntu system by using '%0.19g'

        Good catch. That works with sv_setpvf() in XS, too.
        I'll incorporate it into https://github.com/Dual-Life/Scalar-List-Utils/pull/80 tomorrow.
        AFAIK that pull request does the job fine - but this observation of yours should enable me to reduce a bit of clutter in Makefile.PL and ListUtil.xs.

        Thanks !!

        Cheers,
        Rob
[reply]

In Section Seekers of Perl Wisdom