[emincan2000]

When rounding carries into a new digit, %e prints a two digit mantissa because the exponent is counted before the number is rounded:

lwprintf_snprintf(buf, sizeof(buf), "%.1e", 9.96);   // "10.0e+00", expected "1.0e+01"
lwprintf_snprintf(buf, sizeof(buf), "%.0e", 0.0996); // "10e-02",   expected "1e-01"

%g has the same issue when it picks between f and e style, since the standard uses the exponent after rounding to P - 1 digits:

"%g",   999999.7   // "1000000", expected "1e+06"
"%.2g", 99.96      // "100",     expected "1e+02"
"%.1g", 0.0000997  // "10e-05",  expected "0.0001"

The fix rounds once in e style before the decision, and if the result reached 10 it bumps the exponent and continues with 1.0. The rest of the code is unchanged.

I added these cases to test_basic.c. I also compared against glibc snprintf with random values for %e, %.0e, %.1e, %.3e, %g, %.1g, %.2g, %.3g, %#g, %E, %G and with widths. Every mismatch that went away was one of these carry cases, and no new mismatch appeared. The ones left are the round-half-to-even differences already mentioned in the comment in prv_calculate_dbl_num_data.

I could only build the tests natively on 64-bit here, so the three %p tests that assume a 32-bit pointer fail locally both with and without this change.