<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glibc.git/misc, branch master</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/'/>
<entry>
<title>Enable --enable-fortify-source with clang</title>
<updated>2025-11-21T16:13:11+00:00</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2025-11-20T18:30:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=8d26bed1ebcefd5d2059fd7d7462bdf6593d77fa'/>
<id>8d26bed1ebcefd5d2059fd7d7462bdf6593d77fa</id>
<content type='text'>
clang generates internal calls for some _chk symbol, so add internal
aliases for them, and stub some with rtld-stubbed-symbols to avoid
ld.so linker issues.

Reviewed-by: Sam James &lt;sam@gentoo.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
clang generates internal calls for some _chk symbol, so add internal
aliases for them, and stub some with rtld-stubbed-symbols to avoid
ld.so linker issues.

Reviewed-by: Sam James &lt;sam@gentoo.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Implement C23 const-preserving standard library macros</title>
<updated>2025-11-20T19:31:04+00:00</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2025-11-20T19:30:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=cd748a63ab1a7ae846175c532a3daab341c62690'/>
<id>cd748a63ab1a7ae846175c532a3daab341c62690</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert __HAVE_64B_ATOMICS configure check</title>
<updated>2025-11-14T17:05:20+00:00</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2025-11-13T17:26:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=7fec8a5de6826ef9ae440238d698f0fe5a5fb372'/>
<id>7fec8a5de6826ef9ae440238d698f0fe5a5fb372</id>
<content type='text'>
The 53807741fb44edb8e7c094cb5e7d4ff4e92a6ec1 added a configure check
for 64-bit atomic operations that were not previously enabled on some
32-bit ABIs.

However, the NPTL semaphore code casts a sem_t to a new_sem and issues
a 64-bit atomic operation for __HAVE_64B_ATOMICS.  Since sem_t has
32-bit alignment on 32-bit architectures, this prevents the use of
64-bit atomics even if the ABI supports them.

Assume 64-bit atomic support from __WORDSIZE, which maps to how glibc
defines it before the broken change.  Also rename __HAVE_64B_ATOMICS
to USE_64B_ATOMICS to define better the flag meaning.

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

Reviewed-by: Wilco Dijkstra  &lt;Wilco.Dijkstra@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The 53807741fb44edb8e7c094cb5e7d4ff4e92a6ec1 added a configure check
for 64-bit atomic operations that were not previously enabled on some
32-bit ABIs.

However, the NPTL semaphore code casts a sem_t to a new_sem and issues
a 64-bit atomic operation for __HAVE_64B_ATOMICS.  Since sem_t has
32-bit alignment on 32-bit architectures, this prevents the use of
64-bit atomics even if the ABI supports them.

Assume 64-bit atomic support from __WORDSIZE, which maps to how glibc
defines it before the broken change.  Also rename __HAVE_64B_ATOMICS
to USE_64B_ATOMICS to define better the flag meaning.

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

Reviewed-by: Wilco Dijkstra  &lt;Wilco.Dijkstra@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cdefs: Fix some typos in comments.</title>
<updated>2025-11-11T19:04:29+00:00</updated>
<author>
<name>Bruno Haible</name>
<email>bruno@clisp.org</email>
</author>
<published>2025-11-11T19:04:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=e06a1962e67723c3d6acf14c28a6a7f79ea77ac1'/>
<id>e06a1962e67723c3d6acf14c28a6a7f79ea77ac1</id>
<content type='text'>
Reviewed-by: Collin Funk &lt;collin.funk1@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reviewed-by: Collin Funk &lt;collin.funk1@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>posix: Fix invalid flags test for p{write,read}v2</title>
<updated>2025-11-07T08:57:09+00:00</updated>
<author>
<name>Yury Khrustalev</name>
<email>yury.khrustalev@arm.com</email>
</author>
<published>2025-11-06T12:57:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=58a31b4316f1f687184eb147ffa1c676bc6a190e'/>
<id>58a31b4316f1f687184eb147ffa1c676bc6a190e</id>
<content type='text'>
Two tests fail from time to time when a new flag is added for the
p{write,read}v2 functions in a new Linux kernel:

 - misc/tst-preadvwritev2
 - misc/tst-preadvwritev64v2

This disrupts when testing Glibc on a system with a newer kernel
and it seems we can try improve testing for invalid flags setting
all the bits that are not supposed to be supported (rather than
setting only the next unsupported bit).

Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Two tests fail from time to time when a new flag is added for the
p{write,read}v2 functions in a new Linux kernel:

 - misc/tst-preadvwritev2
 - misc/tst-preadvwritev64v2

This disrupts when testing Glibc on a system with a newer kernel
and it seems we can try improve testing for invalid flags setting
all the bits that are not supposed to be supported (rather than
setting only the next unsupported bit).

Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cdefs: allow __attribute__ on tcc</title>
<updated>2025-10-31T03:03:00+00:00</updated>
<author>
<name>Eric Wong</name>
<email>normalperson@yhbt.net</email>
</author>
<published>2025-10-31T03:03:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=3ac0112b5daa59407f1bedc3b6a6830b6ff00326'/>
<id>3ac0112b5daa59407f1bedc3b6a6830b6ff00326</id>
<content type='text'>
According to the tcc (tiny C compiler) Changelog, tcc supports
__attribute__ since 0.9.3.  Looking at history of tcc at
&lt;https://repo.or.cz/tinycc.git&gt;, __attribute__ support was added
in commit 14658993425878be300aae2e879560698e0c6c4c on 2002-01-03,
which also looks like the release of 0.9.3.  While I'm unable to
find release tags for tcc before 0.9.18 (2003-04-14), the next
release (0.9.28) will include __attribute__((cleanup(func)) which
I rely on.

Reviewed-by: Collin Funk &lt;collin.funk1@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
According to the tcc (tiny C compiler) Changelog, tcc supports
__attribute__ since 0.9.3.  Looking at history of tcc at
&lt;https://repo.or.cz/tinycc.git&gt;, __attribute__ support was added
in commit 14658993425878be300aae2e879560698e0c6c4c on 2002-01-03,
which also looks like the release of 0.9.3.  While I'm unable to
find release tags for tcc before 0.9.18 (2003-04-14), the next
release (0.9.28) will include __attribute__((cleanup(func)) which
I rely on.

Reviewed-by: Collin Funk &lt;collin.funk1@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Cleanup some recently added whitespace.</title>
<updated>2025-10-31T01:56:58+00:00</updated>
<author>
<name>Collin Funk</name>
<email>collin.funk1@gmail.com</email>
</author>
<published>2025-10-30T01:34:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=3fe3f6283302b99b5b2d1615b2a76d20ec791556'/>
<id>3fe3f6283302b99b5b2d1615b2a76d20ec791556</id>
<content type='text'>
Reviewed-by: H.J. Lu &lt;hjl.tools@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reviewed-by: H.J. Lu &lt;hjl.tools@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Annotate swtich fall-through</title>
<updated>2025-10-29T15:54:01+00:00</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2025-10-28T17:08:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=970364dac00b38333e5b2d91c90d11e80141d265'/>
<id>970364dac00b38333e5b2d91c90d11e80141d265</id>
<content type='text'>
The clang default to warning for missing fall-through and it does
not support all comment-like annotation that gcc does.  Use C23
[[fallthrough]] annotation instead.
proper attribute instead.

Reviewed-by: Collin Funk &lt;collin.funk1@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The clang default to warning for missing fall-through and it does
not support all comment-like annotation that gcc does.  Use C23
[[fallthrough]] annotation instead.
proper attribute instead.

Reviewed-by: Collin Funk &lt;collin.funk1@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>misc: Fix clang -Wstring-plus-int warnings on syslog</title>
<updated>2025-10-22T19:35:39+00:00</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2022-04-29T13:50:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=6e862a07f79e931ac790315ccd7e1942d2b42382'/>
<id>6e862a07f79e931ac790315ccd7e1942d2b42382</id>
<content type='text'>
clang issues:

syslog.c:193:9: error: adding 'int' to a string does not append to the string [-Werror,-Wstring-plus-int]
  193 |                       SYSLOG_HEADER (pri, timestamp, &amp;msgoff, pid));
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
syslog.c:180:7: note: expanded from macro 'SYSLOG_HEADER'
  180 |   "[" + (pid == 0), pid, "]" + (pid == 0)

Use array indexes instead of string addition (it is simpler than
add a supress warning).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
clang issues:

syslog.c:193:9: error: adding 'int' to a string does not append to the string [-Werror,-Wstring-plus-int]
  193 |                       SYSLOG_HEADER (pri, timestamp, &amp;msgoff, pid));
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
syslog.c:180:7: note: expanded from macro 'SYSLOG_HEADER'
  180 |   "[" + (pid == 0), pid, "]" + (pid == 0)

Use array indexes instead of string addition (it is simpler than
add a supress warning).
</pre>
</div>
</content>
</entry>
<entry>
<title>atomics: Remove unused atomics</title>
<updated>2025-09-10T09:18:06+00:00</updated>
<author>
<name>Wilco Dijkstra</name>
<email>wilco.dijkstra@arm.com</email>
</author>
<published>2025-09-10T09:07:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=210ee295033c8fb068529f8f408078c418ceb46c'/>
<id>210ee295033c8fb068529f8f408078c418ceb46c</id>
<content type='text'>
Remove all unused atomics.  Replace uses of catomic_increment and
catomic_decrement with atomic_fetch_add_relaxed which maps to a standard
compiler builtin. Relaxed memory ordering is correct for simple counters
since they only need atomicity.

Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove all unused atomics.  Replace uses of catomic_increment and
catomic_decrement with atomic_fetch_add_relaxed which maps to a standard
compiler builtin. Relaxed memory ordering is correct for simple counters
since they only need atomicity.

Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
