Pathologically Eclectic Rubbish Lister | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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.
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: 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 In reply to Re^5: Influencing the Gconvert macro
by syphilis
|
|