Keep It Simple, Stupid | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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 ;-)
Yes - same for my Ubuntu system. That should mean that you should also find that the script I posted in my last post outputs: The unexpected '9.2233720368547758e+18' arises because: 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 In reply to Re^2: [XS] Weird behaviour on some Linux systems
by syphilis
|
|