Re: bin/59749: awk bad test to see if printf supports the %a format

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 06 Nov 2025 12:09:18 -0500
    From:        Christos Zoulas <christos%zoulas.com@localhost>
    Message-ID:  <6aab34136c7132a60ed2a9a26f319d89%zoulas.com@localhost>

  | If upstream changes this, so will we :-)

That looks to be a reasonable way to handle this.

And while I agree that the trailing 0 thing is bogus, and they'd
have no reason to handle that, there is another issue that makes
the test as presented here (I didn't go look at the sources) a poor
one.

That is, all C (or POSIX, which just copies) says about the requirements
for %a format, is that there be at most one hex digit before the '.'.
(Along with the interp rules, %a is lower case hex, ... and all that
more or less irrelevant stuff).   In our implementation, except when the
value of the float is 0.0 I believe the first hex digit (the one before the
'.') is always 1.   That is not required.  All of

	0x1.5p+5 0x2.ap+4 0x5.4p+3 0xa.8p+2

are valid ways to present 42.0 using %a format.   I don't think that
0x0.a8p+6 is valid, but I'm not certain of that one.

Not all versions of libc do this the same way.  Further, if we were
consider 129.0, the 4 ways to present that using %a are:

	0x1.02p+7 0x2.04p+6 0x4.08p+5 0x8.1p+4

which illustrates that perhaps always using a value >=8 for the first
hex digit is the better strategy, as sometimes that will result in either
requiring less digits after the '.', or a more accurate result if that
number is constrained.

That is, it is not impossible that at some time we might alter the
actual value that %a produces.

The "trick" given of just looking for a leading "0x" in the result of a %a
conversion seems like an entirely reasonable one to me - either that, or
convert the result back to a float, and check that that worked, and the
original value is obtained.   (Or I guess, checking all 4 plausible
representations for the value being converted.)

kre