This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

There's been progress on this in #5128, but it's not quite correct yet. The current output of you example is

0x1.fe00000000000p+7

Looks like my implementation isn't quite right.

Some observations from experimenting with printf %a for various integer values.

• It looks like any rendered with %a must have 8, 9, a, b, c, d, e, or f on the left of the decimal point (hexadecimal point?). The digits 0 through 7 are unused. For example, printf "%a 31 is 0xf.8p+1 and printf %a 32 is 0x8p+2.
• If no fractional digits are needed, there is no decimal point. For example, printf %a 18 is 0x9p+1.
• The number of digits after the decimal point is the minimum possible, increasing as needed. For example, printf %a 257 is 0x8.08p+5 but printf %a 258 is 0x8.1p+5.

It looks like the function to update now is format_float_hexadecimal() in src/uucore/src/lib/features/format/num_format.rs. No idea what the right algorithm is though!

Oh, sorry, I didn't notice this issue. I dug into this in #7364 as well. Behaviour is platform-dependent, and we can't get the same precision as x86(-64) by just using Rust's f64.

I think this was fixed in #7631?

Yeah, to the extend this can be "fixed". See #7641 for the documentation of the current behaviour.