y2k/60503: printf locale tests look broken

["kre%munnari.OZ.AU@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60503
>Category:       y2k
>Synopsis:       printf locale tests look broken
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    y2k-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 25 06:00:00 +0000 2026
>Originator:     Robert Elz
>Release:        NetBSD 11.99.6
>Organization:
The Campaign for a "tests" PR category
>Environment:
System: NetBSD jacaranda.noi.kre.to 11.99.6 NetBSD 11.99.6 (JACARANDA:1.1-20260627) #287: Sun Jun 28 03:17:40 +07 2026 kre%jacaranda.noi.kre.to@localhost:/usr/obj/testing/kernels/amd64/JACARANDA amd64
Architecture: x86_64
Machine: amd64
>Description:

Note: I filed this in the "y2k" category, which I assume is little
used today, as there appears to be no good place to report problems
with the ATF tests themselves.   Change it to "misc" or something if
you must!

	src/tests/lib/libc/locale/t_sprintf.c h_sprintf() does

		ATF_REQUIRE_STREQ(setlocale(LC_ALL, "C"), "C");

	that is, ensure the test is started in the C locale, fail otherwise

		ATF_REQUIRE(setlocale(LC_NUMERIC, t->locale) != NULL);

	and then it sets the numeric locale to the one it wants to test,
	and proceeds for format an integer, and a float, using that
	locale.

	For something like the en_US.UTF-8 locale, the first it tests,
	there is no problem.  Similarly for the it_IT.ISO8859-1 locale.

	Note that the locale's would define the charset to use, if
	LC_ALL or LC_CTYPE were set to the local specified, but they
	don't.   That's not a problem for the two tests mentioned, as
	they only produce ascii chars as the result, and those are
	unaltered in both UTF-8 and ISO8859-1 locales.

	But there's a third test performed, using the fr_FR.ISO8859-1
	and for that one, the test expects to receive (and apparently
	does somehow) a \240 (== 0xA0, unbreakable space) as the
	grouping character (thousands separator).   No such character
	exists in the C locale, and it shouldn't be being produced,
	most likely it should turn into a '?' or something.

>How-To-Repeat:
	UTSL.

>Fix:
	No idea.   But something is very fishy here.