http://qs1969.pair.com?node_id=11122392


in reply to Re^4: Influencing the Gconvert macro
in thread Influencing the Gconvert macro

I'd love (someone) to get to the bottom of it, at least to understand if it's a real problem (that needs to be fixed by increasing a buffer size).

I can verify that the "%.*g" formatting still works ok when the buffer size needs to be bigger than 127.
For example, with this patched perl, perl -le 'printf "%.751g\n", 2 ** - 1074;' prints out all 751 mantissa digits correctly and displays the exact decimal rendition of the value 2 ** -1074.
$ ./perl -I./lib -le 'printf "%.751g\n", 2 ** - 1074;' 4.94065... another 740 digits ...65625e-324

Actually, I can add a little to that.
I hacked the source to print out the size of the buffer, and I've just discovered that, so long as I ask for no more than 91 digits, the buffer size is 127 - which should be sufficient.
But as soon as I ask for more than 91 digits, the buffer size is not displayed - indicating that the processing has switched to a different block.
Incredibly, when I ask for more than 91 digits, I've also just now realized that the "%.*g" formatting works fine on Ubuntu-18.04 perls. That is, the bug exists only when I request 18 to 91 (inclusive) digits.
If I request a number outside of that range, it works fine on a standard (unpatched) perl-5.32.0 on Ubuntu-18.04:
$ perl -le 'printf "%.91g\n", 2 ** -1074;' 4.9406564584124654e-324 $ perl -le 'printf "%.92g\n", 2 ** -1074;' 4.94065645841246544176568792868221372365059802614324764425585682500675 +50727020875186529983636e-324
So it looks to me that the concern surrounding the 127-byte buffer is unfounded, because the processing switches to a different block as soon as we ask for more than 91 digits.
But I'm not prepared to claim that I've actually proved anything ;-)

Cheers,
Rob