Re: Bugs in printf/sprintf formatted output

[Maciej W. Rozycki]

On Tue, 6 Aug 2024, arnold@skeeve.com wrote:

> > > Have you had a chance to get to this? I'd like to have it
> > > wrapped up so that I can merge the branch.
> >
> >  Yes, I have started, but it seems to trigger issues here, and I yet need 
> > to figure out whether it's something on my side or a missed case in gawk.  
> > I do hope to get this sorted tomorrow-ish.  I'll keep you posted.
> 
> Thanks.

 Here's the outcome:

- Missing leading zero for signed integer conversions for the specific 
  precision of one above the number of digits required to represent the 
  number and negative numbers, e.g.: { printf "%.2i", -1 } prints "-1" 
  rather than "-01"; similarly { printf "%.3i", -12 }' prints "-12" rather 
  than "-012".  Other precision values or natural numbers work correctly, 
  e.g. { printf "%.3i", -1 } prints "-001" as, { printf "%.2i", 1 } prints 
  "01", etc., as expected.

- The + and space flags not ignored for unsigned integer conversions where 
  the precision specified causes any leading zeros to be printed, e.g.:
  { printf "%+.2u", 1 } prints "+01" rather than "01" and then similarly: 
  { printf "% .3u", 12 } prints " 012" rather than "012".  If no leading 
  zeros are printed, then output is correct, e.g. { printf "%+.2u", 12 } 
  prints "12" as expected.

I find the updated implementation otherwise as expected.

> >  FYI I have submitted the glibc side of this effort now: 
> > <https://sourceware.org/pipermail/libc-alpha/2024-August/158902.html>.
> 
> Wow. Lots of work!

 Thank you.  I'm glad that this test set has helped shaking out some 
issues.

> I see that you found differences in %a between gawk and GLIBC. There too,
> gawk just calls into the C library (or MPFR).  If it's an issue of
> the default precision or something, perhaps I can make a change, but
> you'll need to tell me what's going on.

 It's only MPFR implementation that concerns me here, because obviously 
verifying glibc against itself makes no sense (and I'd expect output to 
match anyway).  According to POSIX with the a and A conversions it is left 
up to the implementation how to represent the value as long as the digit 
before the decimal point is non-zero for normalised numbers and it happens 
that we have a disagreement between implementations here, which is fine.

> > BTW POSIX.1-2024 (Issue 8) has been published now with no `b' or `B' 
> > conversions mentioned, so my understanding is there's no need for gawk to 
> > implement them at this time unless as a GNU extension.
> 
> Those are in C23. But I am in no rush to implement them.

 Yes, as we discussed before, but it is the "Shell & Utilities" volume of 
POSIX rather than ISO C that is binding for AWK.

 There are definitions for formats provided in ISO C that are absent from 
"Shell & Utilities" and do not apply to AWK, such as length modifiers, 
some of which GAWK conveniently silently ignores, such as `h' or `l' as in 
`%hd' and `%ld', and some of which make GAWK stop interpreting the format, 
such as `hh' or `ll' as in `%hhu' and `%llu'.  I don't have an expectation 
for any stuff from outside "Shell & Utilities" to be implemented in GAWK 
and as you can see with the GAWK program included with the glibc test set 
I strip all the length modifiers off for processing so as not to rely on 
this non-standard GAWK extension.

  Maciej