Re: lib/58319: usr.bin/mklocale/Makefile misdefines NBCHAR_MAX

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Fri,  7 Jun 2024 08:05:57 +0000 (UTC)
> From: collin.funk1%gmail.com@localhost
> 
> If someone has access to a NetBSD machine where 'char' is unsigned the following test will be helpful:
> 
>    $ git clone --depth=1 https://git.savannah.gnu.org/git/gnulib.git
>    $ cd gnulib
>    $ ./gnulib-tool --create-testdir --single-configure --dir testdir1 localeconv
>    $ cd testdir1
>    $ ./configure
>    $ make check
> 
> If you see:
> 
>    FAIL: test-localeconv
> 
> then the definition is probably incorrect.

I ran this in NetBSD/aarch64 under qemu, and it printed:

PASS: test-localeconv
...
# TOTAL: 17
# PASS:  17
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

As a side effect, this created two empty directories in /tmp both
called `-p.<randomchars>'.  It looks like the gnulib test suite is not
fully cleaning up after itself, in particular test-init.sh and
test-verify.sh.

> This value is correct since on platforms where char is unsigned it
> will be 255 and not 127. If that Makefile defines NBCHAR_MAX when
> compiling libc then the value will be incorrect. Let me know if that
> explanation makes sense. I'm hoping that someone more familar with
> NetBSD's build system can help.

usr.bin/mklocale/Makefile is used only when compiling the mklocale(1)
program, or when compiling the nbmklocale tool used at build-time to
build the locale files shipped in /usr/share/locale.  The makefiles
used to build libc are all under lib/libc.

The -DNBCHAR_MAX=127 setting in mklocale's makefile came from:

https://mail-index.NetBSD.org/source-changes/2009/01/02/msg214718.html
https://gnats.NetBSD.org/39662

It was prompted by discussion earlier about the locale file format,
but I don't see anything about CHAR_MAX there:

https://mail-index.netbsd.org/tech-userlevel/2008/05/21/msg000591.html

I'm not sure offhand what's going on here.  I toggled it between 127
and 255 in an aarch64 build, and the resulting locale files were
identical.  So empirically it doesn't appear to affect the output.

I'm not familiar enough with the format -- and the documentation for
it isn't obvious enough -- for me to be 100% sure that the value will
never affect the output, but it seems unlikely.

All that said, mklocale doesn't actually use global_locale.c at all.
The use of NBCHAR_MAX in global_locale.c appears to have been a
mistake in this commit:

https://mail-index.NetBSD.org/source-changes/2012/03/21/msg033103.html

Even if mklocale has a legitimate need for the NBCHAR_MAX hook, I see
no reason to use that hook in global_locale.c.  So I'll remove it.

But that still leaves me puzzled about why we have this apparently
harmless but useless NBCHAR_MAX hook in mklocale, with no explanation
in the commit message or history.