Do you know where your variables are? | |
PerlMonks |
Re: [XS] Weird behaviour on some Linux systemsby Haarg (Priest) |
on Oct 12, 2019 at 11:06 UTC ( [id://11107370]=note: print w/replies, xml ) | Need Help?? |
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.
In Section
Seekers of Perl Wisdom
|
|