Clear questions and runnable code
get the best and fastest answer
Re^2: [XS] Weird behaviour on some Linux systemsby syphilis (Bishop)
|on Oct 11, 2019 at 01:45 UTC||Need Help??|
Please check what the NVgf macro expands to on the different platforms ....
The puzzle is that, for certain cases (ie the aforementioned Debian and Ubuntu builds of perl) it apparently expands to different things, depending upon how it is expanded.
I find that mostly:
produce the same result.
That is, the string in "buff" is exactly the same as the string in the PV slot of "keysv".
However, on some systems, with perls whose NV is 'double', and for integer values that require more than 17 digits, the string in "buff" differs from the string in the PV slot of "keysv".
Corion has suggested that this might be explained in terms of differences between perl's sprintf() and libc's sprintf().
My only reason for doubting him is that in 15 years of fiddling around with (s)printf on these systems, I have encountered no such issue. (But as soon as I start trying to get NVgf to work as I expect with sv_setpvf, I hit issues.)
... and check what ANSI C and POSIX say that conversion is supposed to actually do
Yes ... I've had no luck in finding any info on "NVgf" anywhere.
However, I've just found that replacing:
makes no difference at all (at least when NV is 'double').
Given that I reckon I know what "%.19g" should expand to, this would suggest that I don't really need to wonder about what NVgf expands to - rather concentrate more on what sv_setpvf is doing (and on Corion's suggestion).
Or just settle for the workaround that I've already got :-)