|Just another Perl shrine|
Re^4: [XS] Weird behaviour on some Linux systemsby syphilis (Bishop)
|on Oct 12, 2019 at 01:31 UTC||Need Help??|
I think we can forget all about "NVgf". It has nothing to do with the problem.
Below is a shorter, clearer demonstration of the issue - one that makes no mention of "NVgf".
It's really only of interest when run on a perl whose perl -V:nvsize is 8.
If anyone can get this script to pass its test on such a perl on Ubuntu, then I'd love to see the perl -V output and also the Ubuntu version number.
I can see only 2 possible explanations for the test failing:
1) it's a bug in the way that sv_setpvf assigns the string to the SV;
2) it's something that I haven't yet thought of
I've gone cold on the notion that there's something invalid about using sprintf in the XS environment.
It's the one that's delivering the sane result, agreeing both with what happens in the C environment and with what I expect.
I'll ultimately post that demo script in a bug report to RT (and provide a link to it here) unless someone can convince me that there's no perl bug.
I am guessing that sv_setpvf behaves like C sprintf but puts the result into a Perl SV
Yes, that's right - sprintf writes to a string buffer, sv_setpvf writes directly to the SV's PV slot.
The perlclib documentation specifically recommends using sv_setpvf instead of sprintf, which would not be very good advice if sv_setpvf is buggy.