It looks like the code can be made a tiny bit smaller by doing:

if (u_int * 10 > f_int) {
    break;
}
u_int *= 10;
++e;

I specifically didn't do this because at the limit u_int is > INT_MAX / 10, so you get overflow in the comparison

But... it's the same code, no?

Note that I limit the loop to 9 steps. So it never attempts to calculate u_int as 10^10 (which would overflow), it just ends the loop at 10^9. This is OK because of the test above, which ensures f is not bigger than 4e9.

I agree the code is a trap for the unwary as it stands.

Is this code all based around formatting single precision floats well? Or does it also work for double precision? Maybe f_int and u_int need to be uint64_t when mp_float_t is configured to be double?

It works for double precision, but still only applies for numbers up to 2^32. We could go further by extending to 64 bits, but I think the vast majority of cases of interest are covered by the existing code.

The current code stops "working" around 2^32. For a float32-based build:

>>> print("{:f}".format(4294967167))
4294967040.000000
>>> print("{:f}".format(4294967168))
4294967174.530029

i.e. the first number passes the test on line 268 (but then suffers precision loss since the whole value is only stored with 23 bits). The second number, after casting into a float32, does not pass the test and is formatted according to the old code path, with the resulting fractional noise.

It would be possible to make this work for any whole-valued float but I wouldn't be able to use the trick of casting into int32s. However, I'm disappointed by the code size results. Maybe my original pure-float approach was better.