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

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/59749; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
        trevor.zacks%btopenworld.com@localhost
Subject: Re: bin/59749: awk bad test to see if printf supports the %a format
Date: Fri, 07 Nov 2025 07:33:49 +0700

     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