awk and stdio-common/tst-printf-format-as-double* trouble (mpfr support needed)

[Maciej W. Rozycki]

On Wed, 18 Dec 2024, Adhemerval Zanella Netto wrote:

> > A quick look at stdio-common/tst-printf-format-double.sh made me suspect
> > the arbitrary precision (mpfr) support. Indeed, recompiling Gnu awk with
> > that and re-testing, the testsuite passes just fine (zero failures).
> > 
> > 1) Seems like the FAILs are a bug in the testsuite, since in this case each
> > second test should be unsupported too?
> > 
> > 2) Gnu awk upstream states that the arbitrary precision support is "on parole", 
> > and may go away in a future version. It's probably not a good idea to rely 
> > on it then?
> > https://www.gnu.org/software/gawk/manual/html_node/MPFR-On-Parole.html
> 
> Afaik awk was used as reference printf implementation that does not call
> or rely on libc.  I tend to prefer to use pre-generated results, in the
> same way we check the math results with the math/gen-auto-libm-tests.c,
> but we will ended with a similar issue that how to autogenerate the results
> (for the math case we use mpfr/gmp/mpc as reference).
> 
> Maciej, would be feasible to use pre-generated results instead of checking
> against on awk on every make check (this can improve the testing time 
> as well)? 

 I thought I had included the rationale in the change description, but it 
turns out it was only discussed internally.  Sorry about it.

 The short answer is it is *not* feasible to use pre-generated results, 
because I figured out they would require at least a gigabyte of storage, 
i.e. possibly an order of magnitude more than our current whole source 
tree takes now.

 You can determine it quite easily by running the individual test programs 
and storing data produced to stdout somewhere.  The structure of this data 
is documented in stdio-common/tst-printf-format-skeleton.c and at the very 
least the <VAL> field would have to be permanently recorded.  A quick test 
shows e.g.:

$ .../stdio-common/tst-printf-format-p-ldouble --direct e | sed -n '/^%/s/^.*:\([^:]\+\):$/\1/p' | wc -c
143501792
$ .../stdio-common/tst-printf-format-p-ldouble --direct f | sed -n '/^%/s/^.*:\([^:]\+\):$/\1/p' | wc -c
227613378
$ .../stdio-common/tst-printf-format-p-ldouble --direct g | sed -n '/^%/s/^.*:\([^:]\+\):$/\1/p' | wc -c
137682196

-- with the 128-bit IBM format, and then data for other formats would have 
to be included as well (even if we cheated and handled `%e' vs `%E', etc. 
via postprocessing rather than having individual data records for each 
case variant of the output conversions).

> I am not sure if there is really a requirement for a reference implementation,
> specially one that might generate wrong results in the future.  Maybe we can
> use mpfr printf to get the expected values for format strings.

 Is MPFR printf widely available?  It's the first time I hear of such a 
tool and I've used Linux for almost 30 years now.  Conversely there's GNU 
AWK installed across most glibc-based systems.

 I don't think the old note as to MPFR in GNU AWK documentation should be 
an issue for us: GNU AWK has a maintainer now, Arnold D. Robbins (CC'd), 
who I worked with in the course of making this patchset as I discovered 
numerous bugs in GNU AWK, including in the MPFR part, as documented in the 
change description for commit 7ec4d7e3d1c0 ("stdio-common: Add tests for 
formatted printf output specifiers"), and I found Arnold very positive 
towards it, so I think it would be unfair to his effort to refrain from 
using his work.

 NB I've looked into getting rid of the spurious mtrace failures in the 
case where the corresponding test hasn't been run and a fix might be quite 
easy, but we currently have a mess across Makefiles in the handling of 
these mtrace tests and I'd like to fix that first rather than making 
things even messier.  Since this only triggers for installations with a 
crippled compilation of GNU AWK I think it's not a high priority item and 
therefore I chose to defer it until early next year once I'm done with the 
current stuff on my plate now.  I do hope it's acceptable.

  Maciej