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

["Christos Zoulas via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Christos Zoulas <christos%zoulas.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 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: Thu, 06 Nov 2025 12:09:18 -0500

 On 2025-11-06 11:30 am, via gnats wrote:
 > The following reply was made to PR bin/59749; it has been noted by 
 > GNATS.
 > 
 > From: <trevor.zacks%btopenworld.com@localhost>
 > To: <gnats-bugs%netbsd.org@localhost>
 > Cc:
 > Subject: RE: bin/59749: awk bad test to see if printf supports the %a 
 > format
 > Date: Thu, 6 Nov 2025 16:28:27 -0000
 > 
 >  Ah,
 >  	I think I have been somewhat 'economical' with the details of this.
 >  Am porting (n)awk to windows using Microsoft Vis C++ 2022.
 >  The printf man page says -
 > 
 >  a 	Floating-point 	Signed hexadecimal double-precision floating-point
 >  value that has the form
 >  [-]0xh.hhhhp[+|-]dd, where h.hhhh are the hex digits (using lower case
 >  letters) of the mantissa, and dd are one or more digits for the 
 > exponent.
 >  The precision specifies the number of digits after the point.
 > 
 >  Default precision is 13. If precision is 0, no decimal point is 
 > printed
 >  unless the # flag is used.
 >                                  ^^^^
 >                      This would seem to be a lie
 >  But anyway ...
 > 
 >  Close this if feel there is nothing to do
 
 Looks like a windows UCRT issue as Martin noted. I would raise this
 issue with https://github.com/onetrueawk/awk (our upstream) as a 
 portability
 concern. If upstream changes this, so will we :-)
 
 Best,
 
 christos