glibc.git/manual, branch master Unnamed repository; edit this file 'description' to name the repository. Implement C23 const-preserving standard library macros 2025-11-20T19:31:04+00:00 Joseph Myers josmyers@redhat.com 2025-11-20T19:30:27+00:00 cd748a63ab1a7ae846175c532a3daab341c62690 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. 
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.
malloc: add free_sized and free_aligned_sized from C23 2025-11-19T16:47:53+00:00 Justin King jcking@google.com 2025-10-22T12:51:43+00:00 56549264d1e1723dc8ad9675141f316dc83626b3 Signed-off-by: Justin King <jcking@google.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> 
Signed-off-by: Justin King <jcking@google.com>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
Remove support for lock elision. 2025-11-18T13:21:13+00:00 Stefan Liebler stli@linux.ibm.com 2025-10-28T14:21:18+00:00 b9579342c68baf0beacfb4e93b9a6a325d3f9527 The support for lock elision was already deprecated with glibc 2.42: commit 77438db8cfa6ee66b3906230156bdae11c49a195 "Mark support for lock elision as deprecated." See also discussions: https://sourceware.org/pipermail/libc-alpha/2025-July/168492.html This patch removes the architecture specific support for lock elision for x86, powerpc and s390 by removing the elision-conf.h, elision-conf.c, elision-lock.c, elision-timed.c, elision-unlock.c, elide.h, htm.h/hle.h files. Those generic files are also removed. The architecture specific structures are adjusted and the elision fields are marked as unused. See struct_mutex.h files. Furthermore in struct_rwlock.h, the leftover __rwelision was also removed. Those were originally removed with commit 0377a7fde6dfcc078dda29a1225d7720a0931357 "nptl: Remove rwlock elision definitions" and by chance reintroduced with commit 7df8af43ad1cd8ce527444de50bee6f35eebe071 "nptl: Add struct_rwlock.h" The common code (e.g. the pthread_mutex-files) are changed back to the time before lock elision was introduced with the x86-support: - commit 1cdbe579482c07e9f4bb3baa4864da2d3e7eb837 "Add the low level infrastructure for pthreads lock elision with TSX" - commit b023e4ca99f5e81f90d87d23cd267ef2abd2388c "Add new internal mutex type flags for elision." - commit 68cc29355f3334c7ad18f648ff9a6383a0916d23 "Add minimal test suite changes for elision enabled kernels" - commit e8c659d74e011346785355eeef03b7fb6f533c61 "Add elision to pthread_mutex_{try,timed,un}lock" - commit 49186d21ef2d87986bccaf0a7c45c48c91b265f3 "Disable elision for any pthread_mutexattr_settype call" - commit 1717da59aed9612becd56aaa1249aac695af4c8a "Add a configure option to enable lock elision and disable by default" Elision is removed also from the tunables, the initialization part, the pretty-printers and the manual. Some extra handling in the testsuite is removed as well as the full tst-mutex10 testcase, which tested a race while enabling lock elision. I've also searched the code for "elision", "elide", "transaction" and e.g. cleaned some comments. I've run the testsuite on x86_64 and s390x and run the build-many-glibcs.py script. Thanks to Sachin Monga, this patch is also tested on powerpc. A NEWS entry also mentions the removal. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com> 
The support for lock elision was already deprecated with glibc 2.42:
commit 77438db8cfa6ee66b3906230156bdae11c49a195
"Mark support for lock elision as deprecated."
See also discussions:
https://sourceware.org/pipermail/libc-alpha/2025-July/168492.html

This patch removes the architecture specific support for lock elision
for x86, powerpc and s390 by removing the elision-conf.h, elision-conf.c,
elision-lock.c, elision-timed.c, elision-unlock.c, elide.h, htm.h/hle.h files.
Those generic files are also removed.

The architecture specific structures are adjusted and the elision fields are
marked as unused.  See struct_mutex.h files.
Furthermore in struct_rwlock.h, the leftover __rwelision was also removed.
Those were originally removed with commit 0377a7fde6dfcc078dda29a1225d7720a0931357
"nptl: Remove rwlock elision definitions"
and by chance reintroduced with commit 7df8af43ad1cd8ce527444de50bee6f35eebe071
"nptl: Add struct_rwlock.h"

The common code (e.g. the pthread_mutex-files) are changed back to the time
before lock elision was introduced with the x86-support:
- commit 1cdbe579482c07e9f4bb3baa4864da2d3e7eb837
"Add the low level infrastructure for pthreads lock elision with TSX"
- commit b023e4ca99f5e81f90d87d23cd267ef2abd2388c
"Add new internal mutex type flags for elision."
- commit 68cc29355f3334c7ad18f648ff9a6383a0916d23
"Add minimal test suite changes for elision enabled kernels"
- commit e8c659d74e011346785355eeef03b7fb6f533c61
"Add elision to pthread_mutex_{try,timed,un}lock"
- commit 49186d21ef2d87986bccaf0a7c45c48c91b265f3
"Disable elision for any pthread_mutexattr_settype call"
- commit 1717da59aed9612becd56aaa1249aac695af4c8a
"Add a configure option to enable lock elision and disable by default"

Elision is removed also from the tunables, the initialization part, the
pretty-printers and the manual.

Some extra handling in the testsuite is removed as well as the full tst-mutex10
testcase, which tested a race while enabling lock elision.

I've also searched the code for "elision", "elide", "transaction" and e.g.
cleaned some comments.

I've run the testsuite on x86_64 and s390x and run the build-many-glibcs.py
script.
Thanks to Sachin Monga, this patch is also tested on powerpc.

A NEWS entry also mentions the removal.
Reviewed-by: Wilco Dijkstra  <Wilco.Dijkstra@arm.com>
manual: don't use the FSF's old address in license text. 2025-11-18T02:46:12+00:00 Collin Funk collin.funk1@gmail.com 2025-11-11T19:49:07+00:00 04eea3aa48df4e45f473f5ee1c7aac6a6e8302bc Update to latest text from Gnulib commit 08f579c56d81cf78c60fcd3568190f97e6e7f684, file doc/lgpl-2.1.texi. Reviewed-by: Florian Weimer <fweimer@redhat.com> 
Update to latest text from Gnulib commit
08f579c56d81cf78c60fcd3568190f97e6e7f684, file doc/lgpl-2.1.texi.

Reviewed-by: Florian Weimer <fweimer@redhat.com>
Change fromfp functions to return floating types following C23 (bug 28327) 2025-11-13T00:04:21+00:00 Joseph Myers josmyers@redhat.com 2025-11-13T00:04:21+00:00 1f79bc48382cc204a9cb0eae1d3cca2515af1f3c As discussed in bug 28327, C23 changed the fromfp functions to return floating types instead of intmax_t / uintmax_t. (Although the motivation in N2548 was reducing the use of intmax_t in library interfaces, the new version does have the advantage of being able to specify arbitrary integer widths for e.g. assigning the result to a _BitInt, as well as being able to indicate an error case in-band with a NaN return.) As with other such changes from interfaces introduced in TS 18661, implement the new types as a replacement for the old ones, with the old functions remaining as compat symbols but not supported as an API. The test generator used for many of the tests is updated to handle both versions of the functions. Tested for x86_64 and x86, and with build-many-glibcs.py. Also tested tgmath tests for x86_64 with GCC 7 to make sure that the modified case for older compilers in <tgmath.h> does work. Also tested for powerpc64le to cover the ldbl-128ibm implementation and the other things that are handled differently for that configuration. The new tests fail for ibm128, but all the failures relate to incorrect signs of zero results and turn out to arise from bugs in the underlying roundl, ceill, truncl and floorl implementations that I've reported in bug 33623, rather than indicating any bug in the actual new implementation of the functions for that format. So given fixes for those functions (which shouldn't be hard, and of course should add to the tests for those functions rather than relying only on indirect testing via fromfp), the fromfp tests should start passing for ibm128 as well. 
As discussed in bug 28327, C23 changed the fromfp functions to return
floating types instead of intmax_t / uintmax_t.  (Although the
motivation in N2548 was reducing the use of intmax_t in library
interfaces, the new version does have the advantage of being able to
specify arbitrary integer widths for e.g. assigning the result to a
_BitInt, as well as being able to indicate an error case in-band with
a NaN return.)

As with other such changes from interfaces introduced in TS 18661,
implement the new types as a replacement for the old ones, with the
old functions remaining as compat symbols but not supported as an API.
The test generator used for many of the tests is updated to handle
both versions of the functions.

Tested for x86_64 and x86, and with build-many-glibcs.py.

Also tested tgmath tests for x86_64 with GCC 7 to make sure that the
modified case for older compilers in <tgmath.h> does work.

Also tested for powerpc64le to cover the ldbl-128ibm implementation
and the other things that are handled differently for that
configuration.  The new tests fail for ibm128, but all the failures
relate to incorrect signs of zero results and turn out to arise from
bugs in the underlying roundl, ceill, truncl and floorl
implementations that I've reported in bug 33623, rather than
indicating any bug in the actual new implementation of the functions
for that format.  So given fixes for those functions (which shouldn't
be hard, and of course should add to the tests for those functions
rather than relying only on indirect testing via fromfp), the fromfp
tests should start passing for ibm128 as well.
linux: Add mseal syscall support 2025-11-12T18:27:28+00:00 Adhemerval Zanella adhemerval.zanella@linaro.org 2025-11-10T18:03:05+00:00 3d52fd274e9cfc74d90786672d927ca82cb40abd It has been added on Linux 6.10 (8be7258aad44b5e25977a98db136f677fa6f4370) as a way to block operations such as mapping, moving to another location, shrinking the size, expanding the size, or modifying it to a pre-existing memory mapping. Although the system only works on 64-bit CPUs, the entrypoint was added for all ABIs (since the kernel might eventually implement it for additional ones and/or the ABI can execute on a 64-bit kernel). Checked on x86_64-linux-gnu and aarch64-linux-gnu. Reviewed-by: Collin Funk <collin.funk1@gmail.com> 
It has been added on Linux 6.10 (8be7258aad44b5e25977a98db136f677fa6f4370)
as a way to block operations such as mapping, moving to another location,
shrinking the size, expanding the size, or modifying it to a pre-existing
memory mapping.

Although the system only works on 64-bit CPUs, the entrypoint was added
for all ABIs (since the kernel might eventually implement it for additional
ones and/or the ABI can execute on a 64-bit kernel).

Checked on x86_64-linux-gnu and aarch64-linux-gnu.

Reviewed-by: Collin Funk <collin.funk1@gmail.com>
stdlib: Do not define once_flag, ONCE_FLAG_INIT for C++ 2025-11-11T17:20:10+00:00 Florian Weimer fweimer@redhat.com 2025-11-11T17:20:10+00:00 2eff71d28946896d085fbd0836ed1394bb55d352 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> 
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 feature test macros for POSIX.1-2024. 2025-11-05T02:00:57+00:00 Collin Funk collin.funk1@gmail.com 2025-05-23T04:00:05+00:00 a5cc3018f31a125f019685b239c6e5a0bf1a272b * include/features.h (_POSIX_C_SOURCE): Document the value of 202405L for POSIX.1-2024. Set it to 202405L when _GNU_SOURCE or _DEFAULT_SOURCE is defined. (_XOPEN_SOURCE): Document the value of 800 for POSIX-1.2024. Set it to 800 when _GNU_SOURCE is defined. (__USE_XOPEN2K24, __USE_XOPEN2K24XSI): New internal macros. Set them when _POSIX_C_SOURCE is 202405L or greater and/or when _XOPEN_SOURCE is 800 or greater. * manual/creature.texi (Feature Test Macros): Document the new values for _POSIX_C_SOURCE and _XOPEN_SOURCE. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Signed-off-by: Collin Funk <collin.funk1@gmail.com> 
* include/features.h (_POSIX_C_SOURCE): Document the value of 202405L
for POSIX.1-2024.  Set it to 202405L when _GNU_SOURCE or _DEFAULT_SOURCE
is defined.
(_XOPEN_SOURCE): Document the value of 800 for POSIX-1.2024.  Set it to
800 when _GNU_SOURCE is defined.
(__USE_XOPEN2K24, __USE_XOPEN2K24XSI): New internal macros.  Set them
when _POSIX_C_SOURCE is 202405L or greater and/or when _XOPEN_SOURCE is
800 or greater.
* manual/creature.texi (Feature Test Macros): Document the new values
for _POSIX_C_SOURCE and _XOPEN_SOURCE.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Collin Funk <collin.funk1@gmail.com>
docs: Add dynamic linker environment variable docs 2025-11-03T09:47:56+00:00 Frédéric Bérat fberat@redhat.com 2025-10-02T17:15:29+00:00 d4d472366ba69df7b14eba22a75f887b99855d70 The Dynamic Linker chapter now includes a new section detailing environment variables that influence its behavior. This new section documents the `LD_DEBUG` environment variable, explaining how to enable debugging output and listing its various keywords like `libs`, `reloc`, `files`, `symbols`, `bindings`, `versions`, `scopes`, `tls`, `all`, `statistics`, `unused`, and `help`. It also documents `LD_DEBUG_OUTPUT`, which controls where the debug output is written, allowing redirection to a file with the process ID appended. This provides users with essential information for controlling and debugging the dynamic linker. Reviewed-by: DJ Delorie <dj@redhat.com> 
The Dynamic Linker chapter now includes a new section detailing
environment variables that influence its behavior.

This new section documents the `LD_DEBUG` environment variable,
explaining how to enable debugging output and listing its various
keywords like `libs`, `reloc`, `files`, `symbols`, `bindings`,
`versions`, `scopes`, `tls`, `all`, `statistics`, `unused`, and `help`.

It also documents `LD_DEBUG_OUTPUT`, which controls where the debug
output is written, allowing redirection to a file with the process ID
appended.

This provides users with essential information for controlling and
debugging the dynamic linker.

Reviewed-by: DJ Delorie <dj@redhat.com>
Rename uimaxabs to umaxabs (bug 33325) 2025-10-28T12:15:02+00:00 Joseph Myers josmyers@redhat.com 2025-10-28T12:15:02+00:00 096fcdc0a5ca1d3c772a9d10a9bdcc92e6b806ad The C2y function uimaxabs has been renamed to umaxabs. Implement this change in glibc, keeping a compat symbol under the old name, copying the test to test the new name and changing the old test to test the compat symbol. Jakub has done the corresponding change to the built-in function in GCC. Tested for x86_64 and x86. 
The C2y function uimaxabs has been renamed to umaxabs.  Implement this
change in glibc, keeping a compat symbol under the old name, copying
the test to test the new name and changing the old test to test the
compat symbol.  Jakub has done the corresponding change to the
built-in function in GCC.

Tested for x86_64 and x86.