CVS log for src/tests/lib/libc/stdio/t_printf.c

Up to [cvs.NetBSD.org] / src / tests / lib / libc / stdio

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Pull up following revision(s) (requested by riastradh in ticket #787):

	tests/lib/libc/stdio/t_printf.c: revision 1.17
	tests/lib/libc/stdio/t_printf.c: revision 1.18
	lib/libc/gdtoa/hdtoa.c: revision 1.13
	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

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

Revert various broken changes to printf %La (hldtoa).
This reverts:
hdtoa.c 1.12 (PR/56247: Greg A. Woods: printf("%La", LDBL_MIN) dumps core)
hdtoa.c 1.11 (fix tyop)
hdtoa.c 1.10 (Via enh at google dot com in tech-userlevel. Fix handling of
    EXT_FRAC{H,L}BITS (although we don't need to since we don't have them).)

The underlying motivation for this change was that when ld128 is
decomposed into 4x32 words, this hldtoa logic is broken.

But we don't decompose ld128 into 4x32 words; we decompose it into
6x64 words.

And the change, which was supposed to be a noop in our case of 2x64
words (or similar for x87 80-bit floating-point), broke it to the
point of causing buffer overruns (PR 56247) which when worked around
led to just incorrect output output (PR 56937).
If we want to make the #ifdefs for 4x32 words work, that's fine, but
we absolutely must have automatic test cases to detect this kind of
regression because %La formatting is extremely important for
diagnosing details of floating-point data since it doesn't involve
rounding in binary formats.  For now I've added some trivial tests;
there is a more extensive test suite inside gdtoa that we need to
wire up before anyone tries any other shenanigans in this code.

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.

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.

Pull up following revision(s) (requested by riastradh in ticket #1865):

	lib/libc/stdio/Makefile.inc: revision 1.48
	tests/lib/libc/stdio/t_printf.c: revision 1.9
	lib/libc/stdio/vfwprintf.c: revision 1.40
	lib/libc/include/extern.h: revision 1.27
	tests/lib/libc/stdio/t_printf.c: revision 1.10

PR/57250: Martin Husemann: dtoa mishandles infinite doubles on 32bit big
endian machines. When long double support was added, the old code was kept
for the regular double code. This code was never used because WIDE_DOUBLE
was always defined in the Makefile. Remove that old code, and conditionalize
the WIDE_DOUBLE code based on if long doubles are different than doubles on
the specific platform.

Add a test for PR/57250 from Havard Eidnes

Fix the test for "inf" output, also include newline in printf format...

tests/lib/libc/stdio/t_printf: Fix sign error in ld128 case.

Also link back to where the test case came from.

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 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

Revert various broken changes to printf %La (hldtoa).

This reverts:

hdtoa.c 1.12 (PR/56247: Greg A. Woods: printf("%La", LDBL_MIN) dumps core)
hdtoa.c 1.11 (fix tyop)
hdtoa.c 1.10 (Via enh at google dot com in tech-userlevel. Fix handling of
    EXT_FRAC{H,L}BITS (although we don't need to since we don't have them).)

The underlying motivation for this change was that when ld128 is
decomposed into 4x32 words, this hldtoa logic is broken.

But we don't decompose ld128 into 4x32 words; we decompose it into
6x64 words.

And the change, which was supposed to be a noop in our case of 2x64
words (or similar for x87 80-bit floating-point), broke it to the
point of causing buffer overruns (PR 56247) which when worked around
led to just incorrect output output (PR 56937).

If we want to make the #ifdefs for 4x32 words work, that's fine, but
we absolutely must have automatic test cases to detect this kind of
regression because %La formatting is extremely important for
diagnosing details of floating-point data since it doesn't involve
rounding in binary formats.  For now I've added some trivial tests;
there is a more extensive test suite inside gdtoa that we need to
wire up before anyone tries any other shenanigans in this code.

PR lib/56937: printf(3) long double %a formatting is broken

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 %a test the same way.

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: Add a couple simple %La tests.

PR lib/56937: printf(3) long double %a formatting is broken

Pull up following revision(s) (requested by he in ticket #138):

	tests/lib/libc/stdio/t_printf.c: revision 1.9
	tests/lib/libc/stdio/t_printf.c: revision 1.10

Add a test for PR/57250 from Havard Eidnes

Fix the test for "inf" output, also include newline in printf format...

Fix the test for "inf" output, also include newline in printf format...

Add a test for PR/57250 from Havard Eidnes

sync with head

Reduce the number of snprintf(3) invocations, as sparc/qemu timeouts.

Verify that PR lib/22019 is no longer an issue.

Move the references to PRs from code comments to the test description. Once
ATF has the ability to output the metadata in the HTML reports, it should be
easy to traverse between releng and gnats -reports via links.

Pull up following revision(s) (requested by joerg in ticket #119):
	tests/lib/libc/stdio/t_printf.c: revision 1.5
	tests/lib/libc/stdio/t_scanf.c: revision 1.2
	tests/lib/libc/gen/t_humanize_number.c: revision 1.6
Mark w_printf as __printflike and fix a format string error.
Fix format strings to properly quote %.

Fix format strings to properly quote %.

add a test to verify that snprintf float does not leak.

add positional argument tests

Rename few test case names. No functional change.

Split out 't_printf' and 't_scanf' from 't_format' to gain the common
"functional scope" for the test files.