C23 makes various standard library functions, that return a pointer
into an input array, into macros that return a pointer to const when
the relevant argument passed to the macro is a pointer to const.  (The
requirement is for macros, with the existing function types applying
when macro expansion is suppressed.  When a null pointer constant is
passed, such as integer 0, that's the same as a pointer to non-const.)

Implement this feature.  This only applies to C, not C++, since such
macros are not an appropriate way of doing this for C++ and all the
affected functions other than bsearch have overloads to implement an
equivalent feature for C++ anyway.  Nothing is done to apply such a
change to any non-C23 functions with the same property of returning a
pointer into an input array.

The feature is also disabled when _LIBC is defined, since there are
various places in glibc that either redefine these identifiers as
macros, or define the functions themselves, and would need changing to
work in the presence of these macro definitions.  A natural question
is whether we should in fact change those places and not disable the
macro definitions for _LIBC.  If so, we'd need a solution for the
places in glibc that define the macro *before* including the relevant
header (in order in effect to disable the header declaration of the
function by renaming that declaration).

One testcase has #undef added to avoid conflicting with this feature
and another has const added; -Wno-discarded-qualifiers is added for
building zic (but could be removed once there's a new upstream tzcode
release that's const-safe with this C23 change and glibc has updated
to code from that new release).  Probably other places in glibc proper
would need const added if we remove the _LIBC conditionals.

Another question would be whether some GCC extension should be added
to support this feature better with macros that only expand each
argument once (as well as reducing duplication of diagnostics for bad
usages such as non-pointer and pointer-to-volatile-qualfied
arguments).

Tested for x86_64.

Signed-off-by: Justin King <jcking@google.com>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

The definition of once_flag conflicts with std::once_flag in
if “using namespace std;” is active.

Updates commit a7ddbf456d97ac8d1aa7afd735e196a1488bd874
("Add once_flag, ONCE_FLAG_INIT and call_once to stdlib.h for C23").

Suggested-by: Jonathan Wakely <jwakely@redhat.com>
Reviewed-by: Collin Funk <collin.funk1@gmail.com>

Add the C23 memalignment function (query the alignment of a pointer)
to glibc.

Given how simple this operation is, it would make sense for compilers
to inline calls to this function, but I'm treating that as a compiler
matter (compilers should add it as a built-in function) rather than
adding an inline version to glibc headers (although such an inline
version would be reasonable as well).  I've filed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122117 for this feature
in GCC.

Tested for x86_64 and x86.

C23 adds once_flag, ONCE_FLAG_INIT and call_once to stdlib.h (in C11
they were only in threads.h, in C23 they are in both headers; this
change came from N2840).  Implement this change, with a
bits/types/once_flag.h header for the common type and initializer
definitions.

Note that there's an omnibus bug (bug 33001) that covers more than
just these missing definitions.

This doesn't seem a significant enough feature to be worth mentioning
in NEWS.

ISO C is not concerned with whether functions are in libc or
libpthread, but POSIX links this to what header they are declared in,
so functions declared in stdlib.h are supposed to be in libc.
However, the current edition of POSIX is based on C17; hopefully Hurd
glibc will have completed the merge of libpthread into libc (in
particular, moving call_once) well before a future edition of POSIX
based on C23 (or a later version of ISO C) is released.

Tested for x86_64 and x86.

C2Y adds unsigned versions of the abs functions (see C2Y draft N3467 and
proposal N3349).

Tested for x86_64.

Signed-off-by: Lenard Mollenkopf <glibc@lenardmollenkopf.de>

This helps HotColdSplitting in GCC/LLVM.

Thought about doing `exit` as well since its only called once per
process, but since its easy to imagine a hot path leading into
`exit(0)`, its less clear if its profitable.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>

WG14 decided to use the name C23 as the informal name of the next
revision of the C standard (notwithstanding the publication date in
2024).  Update references to C2X in glibc to use the C23 name.

This is intended to update everything *except* where it involves
renaming files (the changes involving renaming tests are intended to
be done separately).  In the case of the _ISOC2X_SOURCE feature test
macro - the only user-visible interface involved - support for that
macro is kept for backwards compatibility, while adding
_ISOC23_SOURCE.

Tested for x86_64.