<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glibc/stdlib/Makefile, branch master</title>
<subtitle>Fork of glibc for development</subtitle>
<id>https://git.zx2c4.com/glibc/atom/stdlib/Makefile?h=master</id>
<link rel='self' href='https://git.zx2c4.com/glibc/atom/stdlib/Makefile?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/'/>
<updated>2024-02-01T17:55:57Z</updated>
<entry>
<title>Rename c2x / gnu2x tests to c23 / gnu23</title>
<updated>2024-02-01T17:55:57Z</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2024-02-01T17:55:57Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=83d8d289b295406e30bc8a079286b093d552c3a5'/>
<id>urn:sha1:83d8d289b295406e30bc8a079286b093d552c3a5</id>
<content type='text'>
Complete the internal renaming from "C2X" and related names in GCC by
renaming *-c2x and *-gnu2x tests to *-c23 and *-gnu23.

Tested for x86_64, and with build-many-glibcs.py for powerpc64le.
</content>
</entry>
<entry>
<title>Refer to C23 in place of C2X in glibc</title>
<updated>2024-02-01T11:02:01Z</updated>
<author>
<name>Joseph Myers</name>
<email>josmyers@redhat.com</email>
</author>
<published>2024-02-01T11:02:01Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=42cc619dfbc44e263239c2de870bae11ad65810a'/>
<id>urn:sha1:42cc619dfbc44e263239c2de870bae11ad65810a</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Use gcc __builtin_stdc_* builtins in stdbit.h if possible</title>
<updated>2024-01-31T18:17:27Z</updated>
<author>
<name>Jakub Jelinek</name>
<email>jakub@redhat.com</email>
</author>
<published>2024-01-31T18:17:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=da89496337b97e6a2aaf1e81d55cf998f6db1070'/>
<id>urn:sha1:da89496337b97e6a2aaf1e81d55cf998f6db1070</id>
<content type='text'>
The following patch uses the GCC 14 __builtin_stdc_* builtins in stdbit.h
for the type-generic macros, so that when compiled with GCC 14 or later,
it supports not just 8/16/32/64-bit unsigned integers, but also 128-bit
(if target supports them) and unsigned _BitInt (any supported precision).
And so that the macros don't expand arguments multiple times and can be
evaluated in constant expressions.

The new testcase is gcc's gcc/testsuite/gcc.dg/builtin-stdc-bit-1.c
adjusted to test stdbit.h and the type-generic macros in there instead
of the builtins and adjusted to use glibc test framework rather than
gcc style tests with __builtin_abort ().

Signed-off-by: Jakub Jelinek &lt;jakub@redhat.com&gt;
Reviewed-by: Joseph Myers &lt;josmyers@redhat.com&gt;
</content>
</entry>
<entry>
<title>stdlib: Reinstate stable mergesort implementation on qsort</title>
<updated>2024-01-15T18:58:35Z</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2024-01-15T14:07:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=709fbd3ec3595f2d1076b4fec09a739327459288'/>
<id>urn:sha1:709fbd3ec3595f2d1076b4fec09a739327459288</id>
<content type='text'>
The mergesort removal from qsort implementation (commit 03bf8357e8)
had the side-effect of making sorting nonstable.  Although neither
POSIX nor C standard specify that qsort should be stable, it seems
that it has become an instance of Hyrum's law where multiple programs
expect it.

Also, the resulting introsort implementation is not faster than
the previous mergesort (which makes the change even less appealing).

This patch restores the previous mergesort implementation, with the
exception of machinery that checks the resulting allocation against
the _SC_PHYS_PAGES (it only adds complexity and the heuristic not
always make sense depending on the system configuration and load).
The alloca usage was replaced with a fixed-size buffer.

For the fallback mechanism, the implementation uses heapsort.  It is
simpler than quicksort, and it does not suffer from adversarial
inputs.  With memory overcommit, it should be rarely triggered.

The drawback is mergesort requires O(n) extra space, and since it is
allocated with malloc the function is AS-signal-unsafe.  It should be
feasible to change it to use mmap, although I am not sure how urgent
it is.  The heapsort is also nonstable, so programs that require a
stable sort would still be subject to this latent issue.

The tst-qsort5 is removed since it will not create quicksort adversarial
inputs with the current qsort_r implementation.

Checked on x86_64-linux-gnu and aarch64-linux-gnu.
Reviewed-by: Florian Weimer &lt;fweimer@redhat.com&gt;
</content>
</entry>
<entry>
<title>Implement C23 &lt;stdbit.h&gt;</title>
<updated>2024-01-03T12:07:14Z</updated>
<author>
<name>Joseph Myers</name>
<email>jsm@polyomino.org.uk</email>
</author>
<published>2024-01-03T12:07:14Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=b34b46b8806a115b86da3b2b22555ad5bffa89d1'/>
<id>urn:sha1:b34b46b8806a115b86da3b2b22555ad5bffa89d1</id>
<content type='text'>
C23 adds a header &lt;stdbit.h&gt; with various functions and type-generic
macros for bit-manipulation of unsigned integers (plus macro defines
related to endianness).  Implement this header for glibc.

The functions have both inline definitions in the header (referenced
by macros defined in the header) and copies with external linkage in
the library (which are implemented in terms of those macros to avoid
duplication).  They are documented in the glibc manual.  Tests, as
well as verifying results for various inputs (of both the macros and
the out-of-line functions), verify the types of those results (which
showed up a bug in an earlier version with the type-generic macro
stdc_has_single_bit wrongly returning a promoted type), that the
macros can be used at top level in a source file (so don't use ({})),
that they evaluate their arguments exactly once, and that the macros
for the type-specific functions have the expected implicit conversions
to the relevant argument type.

Jakub previously referred to -Wconversion warnings in type-generic
macros, so I've included a test with -Wconversion (but the only
warnings I saw and fixed from that test were actually in inline
functions in the &lt;stdbit.h&gt; header - not anything coming from use of
the type-generic macros themselves).

This implementation of the type-generic macros does not handle
unsigned __int128, or unsigned _BitInt types with a width other than
that of a standard integer type (and C23 doesn't require the header to
handle such types either).  Support for those types, using the new
type-generic built-in functions Jakub's added for GCC 14, can
reasonably be added in a followup (along of course with associated
tests).

This implementation doesn't do anything special to handle C++, or have
any tests of functionality in C++ beyond the existing tests that all
headers can be compiled in C++ code; it's not clear exactly what form
this header should take in C++, but probably not one using macros.

DIS ballot comment AT-107 asks for the word "count" to be added to the
names of the stdc_leading_zeros, stdc_leading_ones,
stdc_trailing_zeros and stdc_trailing_ones functions and macros.  I
don't think it's likely to be accepted (accepting any technical
comments would mean having an FDIS ballot), but if it is accepted at
the WG14 meeting (22-26 January in Strasbourg, starting with DIS
ballot comment handling) then there would still be time to update
glibc for the renaming before the 2.39 release.

The new functions and header are placed in the stdlib/ directory in
glibc, rather than creating a new toplevel stdbit/ or putting them in
string/ alongside ffs.

Tested for x86_64 and x86.
</content>
</entry>
<entry>
<title>Add a setjmp/longjmp test between user contexts</title>
<updated>2024-01-01T23:55:38Z</updated>
<author>
<name>H.J. Lu</name>
<email>hjl.tools@gmail.com</email>
</author>
<published>2023-12-20T15:34:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=8d8ae5eebd2c81064cfe88d877940ea4e6046d16'/>
<id>urn:sha1:8d8ae5eebd2c81064cfe88d877940ea4e6046d16</id>
<content type='text'>
Verify that setjmp and longjmp work correctly between user contexts.
Arrange stacks for uctx_func1 and uctx_func2 so that ____longjmp_chk
works when setjmp and longjmp are called from different user contexts.

Reviewed-by: Noah Goldstein &lt;goldstein.w.n@gmail.com&gt;
</content>
</entry>
<entry>
<title>Update copyright dates with scripts/update-copyrights</title>
<updated>2024-01-01T18:53:40Z</updated>
<author>
<name>Paul Eggert</name>
<email>eggert@cs.ucla.edu</email>
</author>
<published>2024-01-01T18:12:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=dff8da6b3e89b986bb7f6b1ec18cf65d5972e307'/>
<id>urn:sha1:dff8da6b3e89b986bb7f6b1ec18cf65d5972e307</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Add a test for setjmp/longjmp within user context</title>
<updated>2023-12-16T16:39:08Z</updated>
<author>
<name>H.J. Lu</name>
<email>hjl.tools@gmail.com</email>
</author>
<published>2023-12-14T19:37:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=49b4de21dcdf364e0dcc57382a8dfa339b59accc'/>
<id>urn:sha1:49b4de21dcdf364e0dcc57382a8dfa339b59accc</id>
<content type='text'>
Verify that setjmp/longjmp works correctly within a user context.
Reviewed-by: Noah Goldstein &lt;goldstein.w.n@gmail.com&gt;
</content>
</entry>
<entry>
<title>Add a test for longjmp from user context</title>
<updated>2023-12-16T16:38:48Z</updated>
<author>
<name>H.J. Lu</name>
<email>hjl.tools@gmail.com</email>
</author>
<published>2023-12-14T19:37:02Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=08bc191fd1603c41f5ddc97ead716e952a556dfd'/>
<id>urn:sha1:08bc191fd1603c41f5ddc97ead716e952a556dfd</id>
<content type='text'>
Verify that longjmp works correctly after setcontext is called to switch
to a user context.
Reviewed-by: Noah Goldstein &lt;goldstein.w.n@gmail.com&gt;
</content>
</entry>
<entry>
<title>stdlib: Fix array bounds protection in insertion sort phase of qsort</title>
<updated>2023-12-04T05:35:56Z</updated>
<author>
<name>Florian Weimer</name>
<email>fweimer@redhat.com</email>
</author>
<published>2023-12-04T05:35:56Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=b9390ba93676c4b1e87e218af5e7e4bb596312ac'/>
<id>urn:sha1:b9390ba93676c4b1e87e218af5e7e4bb596312ac</id>
<content type='text'>
The previous check did not do anything because tmp_ptr already
points before run_ptr due to the way it is initialized.

Fixes commit e4d8117b82065dc72e8df80097360e7c05a349b9
("stdlib: Avoid another self-comparison in qsort").

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