[emincan2000]

Fixes #239.

When %g falls back to decimal mode in print_exponential_number(), the precision becomes precision - floored_exp10, which for small values goes past PRINTF_MAX_SUPPORTED_PRECISION. This limits it again right there, the same way print_floating_point() does. Trailing zeros are only added with #, because without it %g drops trailing zeros, and the zeros put in buf up front wouldn't be dropped.

After the change:

"%.16g"  0.0001    -> 0.0001
"%.16g"  0.000123  -> 0.000123
"%#.16g" 0.001     -> 0.001000000000000000
"%.15g"  0.000338938832258952 -> 0.00033893883225895   (glibc: 0.000338938832258952)

The last one is still shorter than glibc's output, because only 17 decimals are available, but before it printed 0.

Testing:

• Added the first three cases to avoiding_undefined_behavior. They fail without the change; test_suite passes with it (581 assertions on develop).
• Ran 900k random format strings and values (d/i/u/o/x/X with length modifiers, f/e/E/g/G, s, c, with random flags/width/precision up to 15) against glibc under ASan/UBSan: no reports. Compared with the unpatched library, every output that changed was one of these out-of-bounds cases, and none of them got further from glibc's output.

[eyalroz]

What made you choose to skip the fourth check from the bug, here? Is it redundant?

[emincan2000]

Not redundant, it just doesn't pass yet. With the fix %.15g of 0.000338938832258952 prints 0.00033893883225895, while the correct output is 0.000338938832258952: after the fallback that needs 18 decimals, and we only have 17. So a check with the correct value would fail, and checking for the current output would lock in the truncated result.

I could add it commented out, like the beyond-precision checks in tiny_floating_point_values, or check that the output at least starts with 0.000338938832258 (i.e. not 0 anymore). Which would you prefer?

[eyalroz]

Tweaking the comments and the testcase after the merge.