lib/60886: printf(3) in very obscure situations can incorrectly handle the ' flag

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

>Number:         60886
>Category:       lib
>Synopsis:       printf(3) in very obscure situations can incorrectly handle the ' flag
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 15 18:10:00 +0000 2026
>Originator:     Robert Elz
>Release:        NetBSD everything
>Organization:
Apostrophes for Flags.
>Environment:
	[Irrelevant]
>Description:
	In a locale which specifies "thousands" grouping, where the
	first (rightmost) "thousands" group separator is to be inserted
	between the penultimate and final digits, and if the value being
	printed is an integer (not floats, I believe) with a value
	between LONG_MAX and ULONG_MAX or between INTMAX_MAX and UINTMAX_MAX
	and a printf %'d or %'u format (other flags, field width, precision
	etc are all irrelevant) then that rightmost grouping character will
	be inserted before, rather than after, the penultimate digit.

	And yes, it really requires that specific a set of circumstances
	for the bug to manifest,

>How-To-Repeat:
	UTSL.    This was discovered that way, the chances it will be
	seen in the wild are approximately 0 as all real locales (anything
	anyone ever uses) either don't do grouping at all, or group every
	3 characters (real "thousands") and so fail to meet the pre-reqs
	for the bug.

	Once my new locales and updated src/tests/lib/libc/t_sprintf test
	are committed, that test should fail the sprintf test case for
	the new locale which was created specifically to trigger this bug.

	I say "should fail" as it works for me, as I have had the fix for
	this bug in my tree since before the test was written.   I won't
	commit in that order however, I will commit the test, and the locales
	first, and allow the test to fail (if it doesn't, I need to revisit
	how the code works, and see why!) 

	nb: while this is in an area related to the PR 60496 fixes for
	multi-byte decimal points and thousands separators, the bug is
	not at all related to that, and has been present for a long time.

>Fix:
	Just be patient...