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

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

The following reply was made to PR lib/58319; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Collin Funk <collin.funk1%gmail.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: lib/58319: usr.bin/mklocale/Makefile misdefines NBCHAR_MAX
Date: Fri, 7 Jun 2024 13:52:31 +0000

 > Date: Fri,  7 Jun 2024 08:05:57 +0000 (UTC)
 > From: collin.funk1%gmail.com@localhost
 >=20
 > If someone has access to a NetBSD machine where 'char' is unsigned the fo=
 llowing test will be helpful:
 >=20
 >    $ git clone --depth=3D1 https://git.savannah.gnu.org/git/gnulib.git
 >    $ cd gnulib
 >    $ ./gnulib-tool --create-testdir --single-configure --dir testdir1 loc=
 aleconv
 >    $ cd testdir1
 >    $ ./configure
 >    $ make check
 >=20
 > If you see:
 >=20
 >    FAIL: test-localeconv
 >=20
 > 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=3D127 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.