<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glibc.git/sysdeps/unix/sysv/linux/arm/be/libc.abilist, 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>malloc: add free_sized and free_aligned_sized from C23</title>
<updated>2025-11-19T16:47:53+00:00</updated>
<author>
<name>Justin King</name>
<email>jcking@google.com</email>
</author>
<published>2025-10-22T12:51:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=56549264d1e1723dc8ad9675141f316dc83626b3'/>
<id>56549264d1e1723dc8ad9675141f316dc83626b3</id>
<content type='text'>
Signed-off-by: Justin King &lt;jcking@google.com&gt;
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Justin King &lt;jcking@google.com&gt;
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>linux: Add mseal syscall support</title>
<updated>2025-11-12T18:27:28+00:00</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2025-11-10T18:03:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=3d52fd274e9cfc74d90786672d927ca82cb40abd'/>
<id>3d52fd274e9cfc74d90786672d927ca82cb40abd</id>
<content type='text'>
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 &lt;collin.funk1@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;collin.funk1@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Rename uimaxabs to umaxabs (bug 33325)</title>
<updated>2025-10-28T12:15:02+00:00</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2025-10-28T12:15:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=096fcdc0a5ca1d3c772a9d10a9bdcc92e6b806ad'/>
<id>096fcdc0a5ca1d3c772a9d10a9bdcc92e6b806ad</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Implement C23 memalignment</title>
<updated>2025-10-17T16:56:59+00:00</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2025-10-17T16:56:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=ea18d5a4c2583726060326b8a348de0845c22aa1'/>
<id>ea18d5a4c2583726060326b8a348de0845c22aa1</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Implement C23 memset_explicit (bug 32378)</title>
<updated>2025-10-01T15:14:09+00:00</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2025-10-01T15:14:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=0f201f4a817e39c01c502f523d4ea3c91f242767'/>
<id>0f201f4a817e39c01c502f523d4ea3c91f242767</id>
<content type='text'>
Add the C23 memset_explicit function to glibc.  Everything here is
closely based on the approach taken for explicit_bzero.  This includes
the bits that relate to internal uses of explicit_bzero within glibc
(although we don't currently have any such internal uses of
memset_explicit), and also includes the nonnull attribute (when we
move to nonnull_if_nonzero for various functions following C2y, this
function should be included in that change).

The function is declared both for __USE_MISC and for __GLIBC_USE (ISOC23)
(so by default not just for compilers defaulting to C23 mode).

Tested for x86_64 and x86.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add the C23 memset_explicit function to glibc.  Everything here is
closely based on the approach taken for explicit_bzero.  This includes
the bits that relate to internal uses of explicit_bzero within glibc
(although we don't currently have any such internal uses of
memset_explicit), and also includes the nonnull attribute (when we
move to nonnull_if_nonzero for various functions following C2y, this
function should be included in that change).

The function is declared both for __USE_MISC and for __GLIBC_USE (ISOC23)
(so by default not just for compilers defaulting to C23 mode).

Tested for x86_64 and x86.
</pre>
</div>
</content>
</entry>
<entry>
<title>termios: add new baud_t interface, defined to be explicitly numeric</title>
<updated>2025-06-17T12:11:38+00:00</updated>
<author>
<name>H. Peter Anvin (Intel)</name>
<email>hpa@zytor.com</email>
</author>
<published>2025-06-12T01:35:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=5f138519ebdf88e1fc5395d65df0b780dd07829a'/>
<id>5f138519ebdf88e1fc5395d65df0b780dd07829a</id>
<content type='text'>
Add an explicitly numeric interface for baudrate setting. For glibc,
this only announces what is a fair accompli, but this is a plausible
way forward for standardization, and may be possible to infill on
non-compliant systems. The POSIX committee has stated:

[https://www.austingroupbugs.net/view.php?id=1916#c7135]

	A future version of this standard is expected to add at least
	the following symbolic constants for use as values of objects
	of type speed_t: B57600, B115200, B230400, B460800, and
	B921600.

	Implementations are encouraged to propose additional
	interfaces which will make it possible to set and query a
	wider range of speeds than just those enumerated by the
	constants beginning with B. If a set of common interfaces
	emerges between several implementations, a future version of
	this standard will likely add those interfaces.

This is exactly that interface.

The use of the term "baud" is due to the need to have a term
contrasting "speed", and it is already well established as a legacy
term -- including in the names of the legacy Bxxx
constants. Futhermore, it *is* valid from the point of view that the
termios interface fundamentally emulates an RS-232 serial port as far
as the application software is concerned.

The documentation states that for the current version of glibc,
speed_t == baud_t, but explicitly declares that this may not be the
case in the future.

Signed-off-by: H. Peter Anvin (Intel) &lt;hpa@zytor.com&gt;
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add an explicitly numeric interface for baudrate setting. For glibc,
this only announces what is a fair accompli, but this is a plausible
way forward for standardization, and may be possible to infill on
non-compliant systems. The POSIX committee has stated:

[https://www.austingroupbugs.net/view.php?id=1916#c7135]

	A future version of this standard is expected to add at least
	the following symbolic constants for use as values of objects
	of type speed_t: B57600, B115200, B230400, B460800, and
	B921600.

	Implementations are encouraged to propose additional
	interfaces which will make it possible to set and query a
	wider range of speeds than just those enumerated by the
	constants beginning with B. If a set of common interfaces
	emerges between several implementations, a future version of
	this standard will likely add those interfaces.

This is exactly that interface.

The use of the term "baud" is due to the need to have a term
contrasting "speed", and it is already well established as a legacy
term -- including in the names of the legacy Bxxx
constants. Futhermore, it *is* valid from the point of view that the
termios interface fundamentally emulates an RS-232 serial port as far
as the application software is concerned.

The documentation states that for the current version of glibc,
speed_t == baud_t, but explicitly declares that this may not be the
case in the future.

Signed-off-by: H. Peter Anvin (Intel) &lt;hpa@zytor.com&gt;
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>linux: implement arbitrary and split speeds in termios</title>
<updated>2025-06-17T12:11:38+00:00</updated>
<author>
<name>H. Peter Anvin (Intel)</name>
<email>hpa@zytor.com</email>
</author>
<published>2025-06-12T01:35:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=5cf101a85aae0d703cdd8ed7b25fe288e41fdacb'/>
<id>5cf101a85aae0d703cdd8ed7b25fe288e41fdacb</id>
<content type='text'>
Linux has supported arbitrary speeds and split speeds in the kernel
since 2008 on all platforms except Alpha (fixed in 2020), but glibc
was never updated to match. This is further complicated by POSIX uses
of macros for the cf[gs]et[io]speed interfaces, rather than plain
numbers, as it really ought to have.

On most platforms, the glibc ABI includes the c_[io]speed fields in
struct termios, but they are incorrectly used. On MIPS and SPARC, they
are entirely missing.

For backwards compatibility, the kernel will still use the legacy
speed fields unless they are set to BOTHER, and will use the legacy
output speed as the input speed if the latter is 0 (== B0). However,
the specific encoding used is visible to user space applications,
including ones other than the one running.

- SPARC and MIPS get a new struct termios, and tc[gs]etattr() is
  versioned accordingly. However, the new struct termios is set to be
  a strict extension of the old one, which means that cf* interfaces
  other than the speed-related ones do not need versioning.
- The Bxxx constants are redefined as equivalent to their integer
  values and the legacy Bxxx constants are renamed __Bxxx.
- cf[gs]et[io]speed() and cfsetspeed() are versioned accordingly.
- tcgetattr() and cfset[io]speed() are adjusted to always keep the
  c_[io]speed fields correct (unlike earlier versions), but to
  canonicalize the representation to ALSO configure the legacy fields
  if a valid legacy representation exists.
- tcsetattr(), too, canonicalizes the representation in this way
  before passing it to the kernel, to maximize compatibility with
  older applications/tools.
- The old IBAUD0 hack is removed; it is no longer necessary since
  even the legacy c_cflag baud rate fields have had separate input
  values for a long time.

Signed-off-by: H. Peter Anvin (Intel) &lt;hpa@zytor.com&gt;
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Linux has supported arbitrary speeds and split speeds in the kernel
since 2008 on all platforms except Alpha (fixed in 2020), but glibc
was never updated to match. This is further complicated by POSIX uses
of macros for the cf[gs]et[io]speed interfaces, rather than plain
numbers, as it really ought to have.

On most platforms, the glibc ABI includes the c_[io]speed fields in
struct termios, but they are incorrectly used. On MIPS and SPARC, they
are entirely missing.

For backwards compatibility, the kernel will still use the legacy
speed fields unless they are set to BOTHER, and will use the legacy
output speed as the input speed if the latter is 0 (== B0). However,
the specific encoding used is visible to user space applications,
including ones other than the one running.

- SPARC and MIPS get a new struct termios, and tc[gs]etattr() is
  versioned accordingly. However, the new struct termios is set to be
  a strict extension of the old one, which means that cf* interfaces
  other than the speed-related ones do not need versioning.
- The Bxxx constants are redefined as equivalent to their integer
  values and the legacy Bxxx constants are renamed __Bxxx.
- cf[gs]et[io]speed() and cfsetspeed() are versioned accordingly.
- tcgetattr() and cfset[io]speed() are adjusted to always keep the
  c_[io]speed fields correct (unlike earlier versions), but to
  canonicalize the representation to ALSO configure the legacy fields
  if a valid legacy representation exists.
- tcsetattr(), too, canonicalizes the representation in this way
  before passing it to the kernel, to maximize compatibility with
  older applications/tools.
- The old IBAUD0 hack is removed; it is no longer necessary since
  even the legacy c_cflag baud rate fields have had separate input
  values for a long time.

Signed-off-by: H. Peter Anvin (Intel) &lt;hpa@zytor.com&gt;
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>stdlib: Implement C2Y uabs, ulabs, ullabs and uimaxabs</title>
<updated>2025-04-08T12:51:51+00:00</updated>
<author>
<name>Lenard Mollenkopf</name>
<email>glibc@lenardmollenkopf.de</email>
</author>
<published>2025-04-08T12:16:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=5b132ec2b7712dbc055838b3b538b83ad1196414'/>
<id>5b132ec2b7712dbc055838b3b538b83ad1196414</id>
<content type='text'>
C2Y adds unsigned versions of the abs functions (see C2Y draft N3467 and
proposal N3349).

Tested for x86_64.

Signed-off-by: Lenard Mollenkopf &lt;glibc@lenardmollenkopf.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
C2Y adds unsigned versions of the abs functions (see C2Y draft N3467 and
proposal N3349).

Tested for x86_64.

Signed-off-by: Lenard Mollenkopf &lt;glibc@lenardmollenkopf.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Add _FORTIFY_SOURCE support for inet_pton</title>
<updated>2025-03-24T18:43:03+00:00</updated>
<author>
<name>Aaron Merey</name>
<email>amerey@redhat.com</email>
</author>
<published>2025-03-20T17:13:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=e3a6e85d67f1a48dec3e2557a83d6ce1544a58cb'/>
<id>e3a6e85d67f1a48dec3e2557a83d6ce1544a58cb</id>
<content type='text'>
Add function __inet_pton_chk which calls __chk_fail when the size of
argument dst is too small.   inet_pton is redirected to __inet_pton_chk
or __inet_pton_warn when _FORTIFY_SOURCE is &gt; 0.

Also add tests to debug/tst-fortify.c, update the abilist with
__inet_pton_chk and mention inet_pton fortification in maint.texi.

Co-authored-by: Frédéric Bérat &lt;fberat@redhat.com&gt;
Reviewed-by: Florian Weimer &lt;fweimer@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add function __inet_pton_chk which calls __chk_fail when the size of
argument dst is too small.   inet_pton is redirected to __inet_pton_chk
or __inet_pton_warn when _FORTIFY_SOURCE is &gt; 0.

Also add tests to debug/tst-fortify.c, update the abilist with
__inet_pton_chk and mention inet_pton fortification in maint.texi.

Co-authored-by: Frédéric Bérat &lt;fberat@redhat.com&gt;
Reviewed-by: Florian Weimer &lt;fweimer@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Add _FORTIFY_SOURCE support for inet_ntop</title>
<updated>2025-03-21T08:35:42+00:00</updated>
<author>
<name>Frédéric Bérat</name>
<email>fberat@redhat.com</email>
</author>
<published>2025-03-07T17:16:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=090dfa40a5e46f7c0e4d6e8369bcbbd51267625f'/>
<id>090dfa40a5e46f7c0e4d6e8369bcbbd51267625f</id>
<content type='text'>
- Create the __inet_ntop_chk routine that verifies that the builtin size
of the destination buffer is at least as big as the size given by the
user.
- Redirect calls from inet_ntop to __inet_ntop_chk or __inet_ntop_warn
- Update the abilist for this new routine
- Update the manual to mention the new fortification

Reviewed-by: Florian Weimer &lt;fweimer@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- Create the __inet_ntop_chk routine that verifies that the builtin size
of the destination buffer is at least as big as the size given by the
user.
- Redirect calls from inet_ntop to __inet_ntop_chk or __inet_ntop_warn
- Update the abilist for this new routine
- Update the manual to mention the new fortification

Reviewed-by: Florian Weimer &lt;fweimer@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
