Hi,

This has been (partially, sort of) cross-posted at https://github.com/Perl/perl5/issues/18170.

According to the perl source's uconfig.h:

/* Gconvert:
 *    This preprocessor macro is defined to convert a floating point
 *    number to a string without a .  This
 *    emulates the behavior of sprintf("%g"), but is sometimes much mo
+re
 *    efficient.  If gconvert() is not available, but gcvt() drops the
 *    trailing decimal point, then gcvt() is used.  If all else fails,
 *    a macro using sprintf("%g") is used. Arguments for the Gconvert
 *    macro are: value, number of digits, whether trailing zeros shoul
+d
 *    be retained, and the output buffer.
 *    The usual values are:
 *        d_Gconvert='gconvert((x),(n),(t),(b))'
 *        d_Gconvert='gcvt((x),(n),(b))'
 *        d_Gconvert='sprintf((b),"%.*g",(n),(x))'
 *    The last two assume trailing zeros should not be kept.
 */
[download]

Unfortunately, on Ubuntu-18.04, the Gconvert macro uses gcvt() - ie the second option.
It's unfortunate because, on Ubuntu-18.04, it produces (for perls whose nvtype is 'double):

$ perl -le 'printf "%.54g\n", 0.3;'
0.29999999999999999
[download]

Contrast that with(eg) Windows and freebsd-12.0, both of which correctly output:

0.299999999999999988897769753748434595763683319091796875
[download]

The issue is that I want the Gconvert macro on my Ubuntu-18.04 perls (when nvtype is double) to use sprintf() instead of gcvt().
That way, I'll get the correct output, as opposed to the truncated garbage that is currently being displayed.

The question is: "How do I realize that objective ?"
Can I do it via a configure argument when building perl?
Or do I need to do it by hacking the perl source ?

It's a fairly simple hack, if that's what's required.
But I'd prefer to do it via a configure argument, if that's possible.

Cheers,
Rob

PS
I also wonder if people think that this current behaviour on Ubuntu-18.04 should be fixed.
I think it should ... but I shy away from pushing the case because I have this notion that the vast (and I mean VAST) majority of perl practitioners really do not care about it, and would be quite happy for the current behaviour to continue.