NetBSD Problem Report #59749

From www@netbsd.org  Thu Nov  6 13:33:06 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 7C4791A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  6 Nov 2025 13:33:06 +0000 (UTC)
Message-Id: <20251106133305.764261A923C@mollari.NetBSD.org>
Date: Thu,  6 Nov 2025 13:33:05 +0000 (UTC)
From: trevor.zacks@btopenworld.com
Reply-To: trevor.zacks@btopenworld.com
To: gnats-bugs@NetBSD.org
Subject: awk bad test to see if printf supports the %a format
X-Send-Pr-Version: www-1.0

>Number:         59749
>Category:       bin
>Synopsis:       awk bad test to see if printf supports the %a format
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Nov 06 13:35:00 +0000 2025
>Last-Modified:  Fri Nov 07 00:35:01 +0000 2025
>Originator:     Trevor Zacks
>Release:        netbsd 10.1
>Organization:
>Environment:
>Description:
usr/src/external/historical/nawk/dist/run.c

int format(char **pbuf, int *pbufsize, const char *s, Node *a)  /* printf-like conversions */
{
 . . . . . .
        if (first) {
                char xbuf[100];

                snprintf(xbuf, sizeof(xbuf), "%a", 42.0);
                have_a_format = (strcmp(xbuf, "0x1.5p+5") == 0);
                first = false;
        }

Will never match "0x1.5p+5" unless the default printf() precision is 1

>How-To-Repeat:

>Fix:
change

snprintf(xbuf, sizeof(xbuf), "%a", 42.0);

to

snprintf(xbuf, sizeof(xbuf), "%.1a", 42.0);

or just check for "0x" as does GNU

>Audit-Trail:
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/59749: awk bad test to see if printf supports the %a format
Date: Thu, 06 Nov 2025 09:44:07 -0500

 On 2025-11-06 8:35 am, trevor.zacks@btopenworld.com wrote:

 > Will never match "0x1.5p+5" unless the default printf() precision is 1

 I don't understand this statement; there precision in printf(3) is fixed
 by the c standard and baked into libc. This program:

 #include <stdio.h>

 int
 main(void)
 {
          char xbuf[100];
          snprintf(xbuf, sizeof(xbuf), "%a", 42.0);
          printf("%s\n", xbuf);
          return 0;
 }

 prints 0x1.5p+5, so the code as is in awk works?

 christos

From: <trevor.zacks@btopenworld.com>
To: <gnats-bugs@netbsd.org>
Cc: 
Subject: RE: bin/59749: awk bad test to see if printf supports the %a format
Date: Thu, 6 Nov 2025 15:33:49 -0000

 Hi,
 	I tested with

 #include <stdio.h>
 #include <stdlib.h>

 /* awk run.c format() */

 int main( int argc, char *argv[], char *envp[] )
 {
     int have_a_format = 0;

     char xbuf[100];

     snprintf( xbuf, sizeof( xbuf ), "%a", 42.0 );
     have_a_format = ( strcmp( xbuf, "0x1.5p+5" ) == 0 );

     printf( "xbuf:%s:   have_a_format:%d\n", xbuf, have_a_format );

     snprintf( xbuf, sizeof( xbuf ), "%.1a", 42.0 );
     have_a_format = ( strcmp( xbuf, "0x1.5p+5" ) == 0 );

     printf( "xbuf:%s:   have_a_format:%d\n", xbuf, have_a_format );

     return 0;
 }

 And got the output

 xbuf:0x1.5000000000000p+5:   have_a_format:0
 xbuf:0x1.5p+5:   have_a_format:1

 so "%.1a" is correct (for me)

 Enjoy

 -----Original Message-----
 From: Christos Zoulas via gnats <gnats-admin@NetBSD.org> 
 Sent: 06 November 2025 14:45
 To: gnats-admin@netbsd.org; netbsd-bugs@netbsd.org;
 trevor.zacks@btopenworld.com
 Subject: Re: bin/59749: awk bad test to see if printf supports the %a format

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

 From: Christos Zoulas <christos@zoulas.com>
 To: gnats-bugs@netbsd.org
 Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
 Subject: Re: bin/59749: awk bad test to see if printf supports the %a format
 Date: Thu, 06 Nov 2025 09:44:07 -0500

  On 2025-11-06 8:35 am, trevor.zacks@btopenworld.com wrote:

  > Will never match "0x1.5p+5" unless the default printf() precision is 1

  I don't understand this statement; there precision in printf(3) is fixed
 by the c standard and baked into libc. This program:

  #include <stdio.h>

  int
  main(void)
  {
           char xbuf[100];
           snprintf(xbuf, sizeof(xbuf), "%a", 42.0);
           printf("%s\n", xbuf);
           return 0;
  }

  prints 0x1.5p+5, so the code as is in awk works?

  christos


From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
 trevor.zacks@btopenworld.com
Subject: Re: bin/59749: awk bad test to see if printf supports the %a format
Date: Thu, 06 Nov 2025 10:47:19 -0500

 On 2025-11-06 10:40 am, via gnats wrote:
 > The following reply was made to PR bin/59749; it has been noted by 
 > GNATS.
 > 
 > From: <trevor.zacks@btopenworld.com>
 > To: <gnats-bugs@netbsd.org>
 > Cc:
 > Subject: RE: bin/59749: awk bad test to see if printf supports the %a 
 > format
 > Date: Thu, 6 Nov 2025 15:33:49 -0000

 Weird. I ran your program and I get:

 [10:44am] 1822>./a.out
 xbuf:0x1.5p+5:   have_a_format:1
 xbuf:0x1.5p+5:   have_a_format:1

 can you share OS/version/architecture, and also run your program with
 env - ./a.out
 to rule out any environment setup?

 christos

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/59749: awk bad test to see if printf supports the %a format
Date: Thu, 6 Nov 2025 17:22:44 +0100

 On Thu, Nov 06, 2025 at 03:40:01PM +0000,  via gnats wrote:
 >   #include <stdio.h>
 >   
 >   int
 >   main(void)
 >   {
 >            char xbuf[100];
 >            snprintf(xbuf, sizeof(xbuf), "%a", 42.0);
 >            printf("%s\n", xbuf);
 >            return 0;
 >   }
 >   
 >   prints 0x1.5p+5, so the code as is in awk works?

 The windows UCRT seems to get this wrong (according to godbolt.org), while
 all unixish environments seem to get it right.

 Martin

From: <trevor.zacks@btopenworld.com>
To: <gnats-bugs@netbsd.org>
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

 Trevor

 -----Original Message-----
 From: Christos Zoulas via gnats <gnats-admin@NetBSD.org> 
 Sent: 06 November 2025 15:50
 To: gnats-admin@netbsd.org; netbsd-bugs@netbsd.org;
 trevor.zacks@btopenworld.com
 Subject: Re: bin/59749: awk bad test to see if printf supports the %a format

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

 From: Christos Zoulas <christos@zoulas.com>
 To: gnats-bugs@netbsd.org
 Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
 trevor.zacks@btopenworld.com
 Subject: Re: bin/59749: awk bad test to see if printf supports the %a format
 Date: Thu, 06 Nov 2025 10:47:19 -0500

  On 2025-11-06 10:40 am, via gnats wrote:
  > The following reply was made to PR bin/59749; it has been noted by  >
 GNATS.
  >
  > From: <trevor.zacks@btopenworld.com>
  > To: <gnats-bugs@netbsd.org>
  > Cc:
  > Subject: RE: bin/59749: awk bad test to see if printf supports the %a  >
 format  > Date: Thu, 6 Nov 2025 15:33:49 -0000

  Weird. I ran your program and I get:

  [10:44am] 1822>./a.out
  xbuf:0x1.5p+5:   have_a_format:1
  xbuf:0x1.5p+5:   have_a_format:1

  can you share OS/version/architecture, and also run your program with  env
 - ./a.out  to rule out any environment setup?

  christos


From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/59749: awk bad test to see if printf supports the %a format
Date: Thu, 6 Nov 2025 17:41:43 +0100

 I think I read ISO C to say that windows is wrong here.

 When no precision is specified ISO distinguishes
 between FLT_RADIX is a power of 2: the precision is sufficient for
 an exact representation of the value; if FLT_RADIX is not a power of 2
 the precision is enough to distinguish all possible nearby values the
 double type can represent, but trailing zeros may be ommited.

 And of course FLT_RADIX is 2 on all relevant architectures.

 Martin

From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
 trevor.zacks@btopenworld.com
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>
 > To: <gnats-bugs@netbsd.org>
 > 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

From: Robert Elz <kre@munnari.OZ.AU>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
        trevor.zacks@btopenworld.com
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>
     Message-ID:  <6aab34136c7132a60ed2a9a26f319d89@zoulas.com>

   | 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

Home	PR Database Search