CVS commit: [netbsd-9] src/tests/lib/libc/stdio

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Thu Aug 22 19:53:56 UTC 2024

Modified Files:
        src/tests/lib/libc/stdio [netbsd-9]: t_printf.c

Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1866):

        tests/lib/libc/stdio/t_printf.c: revision 1.17
        tests/lib/libc/stdio/t_printf.c: revision 1.18
        tests/lib/libc/stdio/t_printf.c: revision 1.11
        tests/lib/libc/stdio/t_printf.c: revision 1.12
        tests/lib/libc/stdio/t_printf.c: revision 1.13
        tests/lib/libc/stdio/t_printf.c: revision 1.14
        tests/lib/libc/stdio/t_printf.c: revision 1.15
        tests/lib/libc/stdio/t_printf.c: revision 1.16
        (all via patch)

tests/lib/libc/stdio/t_printf: Add a couple simple %La tests.

PR lib/56937: printf(3) long double %a formatting is broken
tests/lib/libc/stdio/t_printf: Fix %La test.
0xa.99ap+0 is closer to (long double)10.6 in x86 ld80 and in
binary128 (and possibly more formats, haven't verified).
tests/lib/libc/stdio/t_printf: Fix %a test the same way.
tests/lib/libc/stdio/t_printf: Add another %La test.

This one was adapted from the screw case shown in
https://mail-index.netbsd.org/tech-userlevel/2020/04/11/msg012329.html
which wasn't broken in our libc, but which nevertheless prompted us
to commit a wrong and apparently untested patch that has rendered
printf %La broken for the last four years, which is a little
embarrassing.  (The part of that patch that led to a buffer overrun
has been worked around, so now the output is just incorrect.)

PR lib/56937: printf(3) long double %a formatting is broken
tests/lib/libc/stdio/t_printf: Fix another rounding error.
Noted by kre.

This doesn't break a passing test or fix a failed test, at least on
x86 -- our printf produces `0x1.533p+3' for the double case and
`0xa.99ap+0' for the long double case.  But of the hexadecimal number
literals that that start with 0x5 having three hexadigits to the
right of the fractional point, 0x5.4cdp+1 closest to the IEEE 754
binary64, VAX D, x86 extended precision, and IEEE 754 binary128
floating-point numbers closest to 10.6.

The reason is that the number 10.6 (or the nearest floating-point
number in any format with enough precision) is:
101.0100 1100 1100|1100... * 2^1 = 0x5.4cc|c...p+1

If we round at the vertical bar to the _nearest_ output with three
hexadigits of precision, the result is:
101.0100 1100 1101 * 2^1 = 0x5.4cdp+1

tests/lib/libc/stdio/t_printf: Fix typo in ld128 case.
printf %La does not write the `L' suffix.

tests/lib/libc/stdio/t_printf: Fix sign error in ld128 case.
Also link back to where the test case came from.


To generate a diff of this commit:
cvs rdiff -u -r1.8.34.1 -r1.8.34.2 src/tests/lib/libc/stdio/t_printf.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.