C2x strtol binary constant handling

C2x adds binary integer constants starting with 0b or 0B, and supports
those constants in strtol-family functions when the base passed is 0
or 2.  Implement that strtol support for glibc.

As discussed at
<https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>,
this is incompatible with previous C standard versions, in that such
an input string starting with 0b or 0B was previously required to be
parsed as 0 (with the rest of the string unprocessed).  Thus, as
proposed there, this patch adds 20 new __isoc23_* functions with
appropriate header redirection support.  This patch does *not* do
anything about scanf %i (which will need 12 new functions per long
double variant, so 12, 24 or 36 depending on the glibc configuration),
instead leaving that for a future patch.  The function names would
remain as __isoc23_* even if C2x ends up published in 2024 rather than
2023.

Making this change leads to the question of what should happen to
internal uses of these functions in glibc and its tests.  The header
redirection (which applies for _GNU_SOURCE or any other feature test
macros enabling C2x features) has the effect of redirecting internal
uses but without those uses then ending up at a hidden alias (see the
comment in include/stdio.h about interaction with libc_hidden_proto).
It seems desirable for the default for internal uses to be the same
versions used by normal code using _GNU_SOURCE, so rather than doing
anything to disable that redirection, similar macro definitions to
those in include/stdio.h are added to the include/ headers for the new
functions.

Given that the default for uses in glibc is for the redirections to
apply, the next question is whether the C2x semantics are correct for
all those uses.  Uses with the base fixed to 10, 16 or any other value
other than 0 or 2 can be ignored.  I think this leaves the following
internal uses to consider (an important consideration for review of
this patch will be both whether this list is complete and whether my
conclusions on all entries in it are correct):

benchtests/bench-malloc-simple.c
benchtests/bench-string.h
elf/sotruss-lib.c
math/libm-test-support.c
nptl/perf.c
nscd/nscd_conf.c
nss/nss_files/files-parse.c
posix/tst-fnmatch.c
posix/wordexp.c
resolv/inet_addr.c
rt/tst-mqueue7.c
soft-fp/testit.c
stdlib/fmtmsg.c
support/support_test_main.c
support/test-container.c
sysdeps/pthread/tst-mutex10.c

I think all of these places are OK with the new semantics, except for
resolv/inet_addr.c, where the POSIX semantics of inet_addr do not
allow for binary constants; thus, I changed that file (to use
__strtoul_internal, whose semantics are unchanged) and added a test
for this case.  In the case of posix/wordexp.c I think accepting
binary constants is OK since POSIX explicitly allows additional forms
of shell arithmetic expressions, and in stdlib/fmtmsg.c SEV_LEVEL is
not in POSIX so again I think accepting binary constants is OK.

Functions such as __strtol_internal, which are only exported for
compatibility with old binaries from when those were used in inline
functions in headers, have unchanged semantics; the __*_l_internal
versions (purely internal to libc and not exported) have a new
argument to specify whether to accept binary constants.

As well as for the standard functions, the header redirection also
applies to the *_l versions (GNU extensions), and to legacy functions
such as strtoq, to avoid confusing inconsistency (the *q functions
redirect to __isoc23_*ll rather than needing their own __isoc23_*
entry points).  For the functions that are only declared with
_GNU_SOURCE, this means the old versions are no longer available for
normal user programs at all.  An internal __GLIBC_USE_C2X_STRTOL macro
is used to control the redirections in the headers, and cases in glibc
that wish to avoid the redirections - the function implementations
themselves and the tests of the old versions of the GNU functions -
then undefine and redefine that macro to allow the old versions to be
accessed.  (There would of course be greater complexity should we wish
to make any of the old versions into compat symbols / avoid them being
defined at all for new glibc ABIs.)

strtol_l.c has some similarity to strtol.c in gnulib, but has already
diverged some way (and isn't listed at all at
https://sourceware.org/glibc/wiki/SharedSourceFiles unlike strtoll.c
and strtoul.c); I haven't made any attempts at gnulib compatibility in
the changes to that file.

I note incidentally that inttypes.h and wchar.h are missing the
__nonnull present on declarations of this family of functions in
stdlib.h; I didn't make any changes in that regard for the new
declarations added.

1 files changed, 28 insertions, 2 deletions

diff --git a/stdlib/strtol_l.c b/stdlib/strtol_l.c
index edbade179b..3424c3feab 100644
--- a/stdlib/strtol_l.c
+++ b/stdlib/strtol_l.c
@@ -16,6 +16,9 @@
    License along with the GNU C Library; if not, see
    <https://www.gnu.org/licenses/>.  */
 
+#include <features.h>
+#undef __GLIBC_USE_C2X_STRTOL
+#define __GLIBC_USE_C2X_STRTOL 0
 
 #if HAVE_CONFIG_H
 # include <config.h>
@@ -61,28 +64,36 @@
 # ifdef USE_WIDE_CHAR
 #  ifdef QUAD
 #   define strtol_l wcstoull_l
+#   define __isoc23_strtol_l __isoc23_wcstoull_l
 #  else
 #   define strtol_l wcstoul_l
+#   define __isoc23_strtol_l __isoc23_wcstoul_l
 #  endif
 # else
 #  ifdef QUAD
 #   define strtol_l strtoull_l
+#   define __isoc23_strtol_l __isoc23_strtoull_l
 #  else
 #   define strtol_l strtoul_l
+#   define __isoc23_strtol_l __isoc23_strtoul_l
 #  endif
 # endif
 #else
 # ifdef USE_WIDE_CHAR
 #  ifdef QUAD
 #   define strtol_l wcstoll_l
+#   define __isoc23_strtol_l __isoc23_wcstoll_l
 #  else
 #   define strtol_l wcstol_l
+#   define __isoc23_strtol_l __isoc23_wcstol_l
 #  endif
 # else
 #  ifdef QUAD
 #   define strtol_l strtoll_l
+#   define __isoc23_strtol_l __isoc23_strtoll_l
 #  else
 #   define strtol_l strtol_l
+#   define __isoc23_strtol_l __isoc23_strtol_l
 #  endif
 # endif
 #endif
@@ -216,12 +227,14 @@ extern const unsigned char __strtol_ull_rem_tab[] attribute_hidden;
    If BASE is 0 the base is determined by the presence of a leading
    zero, indicating octal or a leading "0x" or "0X", indicating hexadecimal.
    If BASE is < 2 or > 36, it is reset to 10.
+   If BIN_CST is true, binary constants starting "0b" or "0B" are accepted
+   in base 0 and 2.
    If ENDPTR is not NULL, a pointer to the character after the last
    one converted is stored in *ENDPTR.  */
 
 INT
 INTERNAL (__strtol_l) (const STRING_TYPE *nptr, STRING_TYPE **endptr,
-		       int base, int group, locale_t loc)
+		       int base, int group, bool bin_cst, locale_t loc)
 {
   int negative;
   unsigned LONG int cutoff;
@@ -311,6 +324,11 @@ INTERNAL (__strtol_l) (const STRING_TYPE *nptr, STRING_TYPE **endptr,
 	  s += 2;
 	  base = 16;
 	}
+      else if (bin_cst && (base == 0 || base == 2) && TOUPPER (s[1]) == L_('B'))
+	{
+	  s += 2;
+	  base = 2;
+	}
       else if (base == 0)
 	base = 8;
     }
@@ -543,7 +561,15 @@ weak_function
 __strtol_l (const STRING_TYPE *nptr, STRING_TYPE **endptr,
 	    int base, locale_t loc)
 {
-  return INTERNAL (__strtol_l) (nptr, endptr, base, 0, loc);
+  return INTERNAL (__strtol_l) (nptr, endptr, base, 0, false, loc);
 }
 libc_hidden_def (__strtol_l)
 weak_alias (__strtol_l, strtol_l)
+
+INT
+__isoc23_strtol_l (const STRING_TYPE *nptr, STRING_TYPE **endptr,
+		   int base, locale_t loc)
+{
+  return INTERNAL (__strtol_l) (nptr, endptr, base, 0, true, loc);
+}
+libc_hidden_def (__isoc23_strtol_l)