about summary refs log tree commit diff
path: root/stdlib
Commit message (Collapse)AuthorAgeFilesLines
* stdlib: Fix stdbit.h with -Wconversion for clangAdhemerval Zanella2024-01-051-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With clang 14 and also with main the tst-stdbit-Wconversion issues the warnings: ../stdlib/stdbit.h:701:40: error: implicit conversion loses integer precision: 'int' to 'uint16_t' (aka 'unsigned short') [-Werror,-Wimplicit-int-conversion] return __x == 0 ? 0 : ((uint16_t) 1) << (__bw16_inline (__x) - 1); ~~~~~~ ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../stdlib/stdbit.h:707:39: error: implicit conversion loses integer precision: 'int' to 'uint8_t' (aka 'unsigned char') [-Werror,-Wimplicit-int-conversion] return __x == 0 ? 0 : ((uint8_t) 1) << (__bw8_inline (__x) - 1); ~~~~~~ ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ ../stdlib/stdbit.h:751:40: error: implicit conversion loses integer precision: 'int' to 'uint16_t' (aka 'unsigned short') [-Werror,-Wimplicit-int-conversion] return __x <= 1 ? 1 : ((uint16_t) 2) << (__bw16_inline (__x - 1) - 1); ~~~~~~ ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../stdlib/stdbit.h:757:39: error: implicit conversion loses integer precision: 'int' to 'uint8_t' (aka 'unsigned char') [-Werror,-Wimplicit-int-conversion] return __x <= 1 ? 1 : ((uint8_t) 2) << (__bw8_inline (__x - 1) - 1); ~~~~~~ ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ tst-stdbit-Wconversion.c:45:31: error: implicit conversion loses integer precision: 'unsigned short' to 'uint8_t' (aka 'unsigned char') [-Werror,-Wimplicit-int-conversion] (void) stdc_trailing_zeros (us); ~~~~~~~~~~~~~~~~~~~~~^~~ ../stdlib/stdbit.h:164:30: note: expanded from macro 'stdc_trailing_zeros' : stdc_trailing_zeros_uc (x)) ~~~~~~~~~~~~~~~~~~~~~~~~^~ ../stdlib/stdbit.h:191:52: note: expanded from macro 'stdc_trailing_zeros_uc' # define stdc_trailing_zeros_uc(x) (__ctz8_inline (x)) ~~~~~~~~~~~~~ ^ tst-stdbit-Wconversion.c:46:31: error: implicit conversion loses integer precision: 'unsigned int' to 'uint16_t' (aka 'unsigned short') [-Werror,-Wimplicit-int-conversion] (void) stdc_trailing_zeros (ui); ~~~~~~~~~~~~~~~~~~~~~^~~ ../stdlib/stdbit.h:163:48: note: expanded from macro 'stdc_trailing_zeros' : sizeof (x) == 2 ? stdc_trailing_zeros_us (x) \ ~~~~~~~~~~~~~~~~~~~~~~~~^~ ../stdlib/stdbit.h:192:53: note: expanded from macro 'stdc_trailing_zeros_us' # define stdc_trailing_zeros_us(x) (__ctz16_inline (x)) ~~~~~~~~~~~~~~ ^ tst-stdbit-Wconversion.c:46:31: error: implicit conversion loses integer precision: 'unsigned int' to 'uint8_t' (aka 'unsigned char') [-Werror,-Wimplicit-int-conversion] (void) stdc_trailing_zeros (ui); ~~~~~~~~~~~~~~~~~~~~~^~~ ../stdlib/stdbit.h:164:30: note: expanded from macro 'stdc_trailing_zeros' : stdc_trailing_zeros_uc (x)) ~~~~~~~~~~~~~~~~~~~~~~~~^~ ../stdlib/stdbit.h:191:52: note: expanded from macro 'stdc_trailing_zeros_uc' # define stdc_trailing_zeros_uc(x) (__ctz8_inline (x)) ~~~~~~~~~~~~~ ^ tst-stdbit-Wconversion.c:47:31: error: implicit conversion loses integer precision: 'unsigned long' to 'uint16_t' (aka 'unsigned short') [-Werror,-Wimplicit-int-conversion] (void) stdc_trailing_zeros (ul); ~~~~~~~~~~~~~~~~~~~~~^~~ ../stdlib/stdbit.h:163:48: note: expanded from macro 'stdc_trailing_zeros' : sizeof (x) == 2 ? stdc_trailing_zeros_us (x) \ ~~~~~~~~~~~~~~~~~~~~~~~~^~ ../stdlib/stdbit.h:192:53: note: expanded from macro 'stdc_trailing_zeros_us' # define stdc_trailing_zeros_us(x) (__ctz16_inline (x)) ~~~~~~~~~~~~~~ ^ [...] It seems to boiler down to __builtin_clz not having a variant for 8 or 16 bits. Fix it by explicit casting to the expected types. Although not strickly required for older gcc, using the same __pacify macro simpify the required code. Checked on x86_64-linux-gnu and i686-linux-gnu.
* stdlib: Fix stdbit.h with -Wconversion for older gccAdhemerval Zanella2024-01-051-8/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With gcc 6.5.0, 7.5.0, 8.5.0, and 9.5.0 the tst-stdbit-Wconversion issues the warnings: ../stdlib/stdbit.h: In function ‘__clo16_inline’: ../stdlib/stdbit.h:128:26: error: conversion to ‘uint16_t {aka short unsigned int}’ from ‘int’ may alter its value [-Werror=conversion] return __clz16_inline (~__x); ^ ../stdlib/stdbit.h: In function ‘__clo8_inline’: ../stdlib/stdbit.h:134:25: error: conversion to ‘uint8_t {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion] return __clz8_inline (~__x); ^ ../stdlib/stdbit.h: In function ‘__cto16_inline’: ../stdlib/stdbit.h:232:26: error: conversion to ‘uint16_t {aka short unsigned int}’ from ‘int’ may alter its value [-Werror=conversion] return __ctz16_inline (~__x); ^ ../stdlib/stdbit.h: In function ‘__cto8_inline’: ../stdlib/stdbit.h:238:25: error: conversion to ‘uint8_t {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion] return __ctz8_inline (~__x); ^ ../stdlib/stdbit.h: In function ‘__bf16_inline’: ../stdlib/stdbit.h:701:23: error: conversion to ‘uint16_t {aka short unsigned int}’ from ‘int’ may alter its value [-Werror=conversion] return __x == 0 ? 0 : ((uint16_t) 1) << (__bw16_inline (__x) - 1); ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../stdlib/stdbit.h: In function ‘__bf8_inline’: ../stdlib/stdbit.h:707:23: error: conversion to ‘uint8_t {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion] return __x == 0 ? 0 : ((uint8_t) 1) << (__bw8_inline (__x) - 1); ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../stdlib/stdbit.h: In function ‘__bc16_inline’: ../stdlib/stdbit.h:751:59: error: conversion to ‘uint16_t {aka short unsigned int}’ from ‘int’ may alter its value [-Werror=conversion] return __x <= 1 ? 1 : ((uint16_t) 2) << (__bw16_inline (__x - 1) - 1); ^~~ ../stdlib/stdbit.h:751:23: error: conversion to ‘uint16_t {aka short unsigned int}’ from ‘int’ may alter its value [-Werror=conversion] return __x <= 1 ? 1 : ((uint16_t) 2) << (__bw16_inline (__x - 1) - 1); ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../stdlib/stdbit.h: In function ‘__bc8_inline’: ../stdlib/stdbit.h:757:57: error: conversion to ‘uint8_t {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion] return __x <= 1 ? 1 : ((uint8_t) 2) << (__bw8_inline (__x - 1) - 1); ^~~ ../stdlib/stdbit.h:757:23: error: conversion to ‘uint8_t {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion] return __x <= 1 ? 1 : ((uint8_t) 2) << (__bw8_inline (__x - 1) - 1); It seems to boiler down to __builtin_clz not having a variant for 8 or 16 bits. Fix it by explicit casting to the expected types. Checked on x86_64-linux-gnu and i686-linux-gnu with gcc 9.5.0.
* Implement C23 <stdbit.h>Joseph Myers2024-01-0390-12/+4236
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C23 adds a header <stdbit.h> 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 <stdbit.h> 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.
* Add a setjmp/longjmp test between user contextsH.J. Lu2024-01-012-0/+139
| | | | | | | | 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 <goldstein.w.n@gmail.com>
* Update copyright dates with scripts/update-copyrightsPaul Eggert2024-01-01230-230/+230
|
* tst-setcontext10.c: Undef _FORTIFY_SOURCEH.J. Lu2023-12-191-0/+9
| | | | | | | | | | | When _FORTIFY_SOURCE is defined to 2, ____longjmp_chk is called, instead of longjmp. ____longjmp_chk compares the relative stack values to decide if it is called from a stack frame which called setjmp. If not, ____longjmp_chk assumes that an alternate signal stack is used. Since comparing the relative stack values isn't reliable with user context, when there is no signal, ____longjmp_chk will fail. Undefine _FORTIFY_SOURCE to avoid ____longjmp_chk in user context test.
* Add a test for setjmp/longjmp within user contextH.J. Lu2023-12-162-0/+179
| | | | | Verify that setjmp/longjmp works correctly within a user context. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* Add a test for longjmp from user contextH.J. Lu2023-12-162-0/+88
| | | | | | Verify that longjmp works correctly after setcontext is called to switch to a user context. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* stdlib: Fix array bounds protection in insertion sort phase of qsortFlorian Weimer2023-12-043-1/+62
| | | | | | | | | | 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 <adhemerval.zanella@linaro.org>
* stdlib: The qsort implementation needs to use heapsort in more casesFlorian Weimer2023-11-213-4/+187
| | | | | | | | | | | | The existing logic avoided internal stack overflow. To avoid a denial-of-service condition with adversarial input, it is necessary to fall over to heapsort if tail-recursing deeply, too, which does not result in a deep stack of pending partitions. The new test stdlib/tst-qsort5 is based on Douglas McIlroy's paper on this subject. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdlib: Handle various corner cases in the fallback heapsort for qsortFlorian Weimer2023-11-213-17/+173
| | | | | | | | | | | | The previous implementation did not consistently apply the rule that the child nodes of node K are at 2 * K + 1 and 2 * K + 2, or that the parent node is at (K - 1) / 2. Add an internal test that targets the heapsort implementation directly. Reported-by: Stepan Golosunov <stepan@golosunov.pp.ru> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdlib: Avoid another self-comparison in qsortFlorian Weimer2023-11-211-1/+1
| | | | | | | | In the insertion phase, we could run off the start of the array if the comparison function never runs zero. In that case, it never finds the initial element that terminates the iteration. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdlib: Avoid element self-comparisons in qsortFlorian Weimer2023-11-081-3/+5
| | | | | | | | | | | This improves compatibility with applications which assume that qsort does not invoke the comparison function with equal pointer arguments. The newly introduced branches should be predictable, as leading to a call to the comparison function. If the prediction fails, we avoid calling the function. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdlib: Add more qsort{_r} coverageAdhemerval Zanella2023-10-312-0/+367
| | | | | | | | | | | This patch adds a qsort and qsort_r to trigger the worst case scenario for the quicksort (which glibc current lacks coverage). The test is done with random input, dfferent internal types (uint8_t, uint16_t, uint32_t, uint64_t, large size), and with different set of element numbers. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* stdlib: Remove use of mergesort on qsort (BZ 21719)Adhemerval Zanella2023-10-313-314/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes the mergesort optimization on qsort implementation and uses the introsort instead. The mergesort implementation has some issues: - It is as-safe only for certain types sizes (if total size is less than 1 KB with large element sizes also forcing memory allocation) which contradicts the function documentation. Although not required by the C standard, it is preferable and doable to have an O(1) space implementation. - The malloc for certain element size and element number adds arbitrary latency (might even be worse if malloc is interposed). - To avoid trigger swap from memory allocation the implementation relies on system information that might be virtualized (for instance VMs with overcommit memory) which might lead to potentially use of swap even if system advertise more memory than actually has. The check also have the downside of issuing syscalls where none is expected (although only once per execution). - The mergesort is suboptimal on an already sorted array (BZ#21719). The introsort implementation is already optimized to use constant extra space (due to the limit of total number of elements from maximum VM size) and thus can be used to avoid the malloc usage issues. Resulting performance is slower due the usage of qsort, specially in the worst-case scenario (partialy or sorted arrays) and due the fact mergesort uses a slight improved swap operations. This change also renders the BZ#21719 fix unrequired (since it is meant to fix the sorted input performance degradation for mergesort). The manual is also updated to indicate the function is now async-cancel safe. Checked on x86_64-linux-gnu. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* stdlib: Implement introsort for qsort (BZ 19305)Adhemerval Zanella2023-10-311-7/+82
| | | | | | | | | | This patch makes the quicksort implementation to acts as introsort, to avoid worse-case performance (and thus making it O(nlog n)). It switch to heapsort when the depth level reaches 2*log2(total elements). The heapsort is a textbook implementation. Checked on x86_64-linux-gnu and aarch64-linux-gnu. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* stdlib: qsort: Move some macros to inline functionAdhemerval Zanella2023-10-311-12/+23
| | | | Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* stdlib: Move insertion sort out qsortAdhemerval Zanella2023-10-311-47/+54
| | | | Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* stdlib: Optimization qsort{_r} swap implementationAdhemerval Zanella2023-10-311-18/+77
| | | | | | | | | | | | The optimization takes in consideration both the most common elements are either 32 or 64 bit in size and inputs are aligned to the word boundary. This is similar to what msort does. For large buffer the swap operation uses memcpy/mempcpy with a small fixed size buffer (so compiler might inline the operations). Checked on x86_64-linux-gnu. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* stdlib: fix grouping verification with multi-byte thousands separator (bug ↵Andreas Schwab2023-10-122-24/+13
| | | | | | | | | 30964) The grouping verification only worked for a single-byte thousands separator. With a multi-byte separator it returned as if no separators were present. The actual parsing in str_to_mpn will then go wrong when there are multiple adjacent multi-byte separators in the number.
* __call_tls_dtors: Use call_function_static_weakSamuel Thibault2023-09-041-5/+2
|
* tst-realpath-toolong: return "unsupported" when PATH_MAX is undefinedSamuel Thibault2023-08-031-4/+5
| | | | | When PATH_MAX is undefined, realpath cannot ever ENAMETOOLONG, so this test is unsupported.
* stdlib: Improve tst-realpath compatibility with source fortificationFlorian Weimer2023-08-011-1/+6
| | | | | | On GCC before 11, IPA can make the fortified realpath aware that the buffer size is not large enough (8 bytes instead of PATH_MAX bytes). Fix this by using a buffer that is large enough.
* Exclude routines from fortificationFrédéric Bérat2023-07-051-0/+7
| | | | | | | | | | | | | | | | | Since the _FORTIFY_SOURCE feature uses some routines of Glibc, they need to be excluded from the fortification. On top of that: - some tests explicitly verify that some level of fortification works appropriately, we therefore shouldn't modify the level set for them. - some objects need to be build with optimization disabled, which prevents _FORTIFY_SOURCE to be used for them. Assembler files that implement architecture specific versions of the fortified routines were not excluded from _FORTIFY_SOURCE as there is no C header included that would impact their behavior. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* setenv.c: Get rid of alloca.Joe Simmons-Talbott2023-06-301-34/+6
| | | | | | Use malloc rather than alloca to avoid potential stack overflow. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* C2x scanf %b supportJoseph Myers2023-06-191-0/+22
| | | | | | | | | | | | ISO C2x defines scanf %b for input of binary integers (with an optional 0b or 0B prefix). Implement such support, along with the corresponding SCNb* macros in <inttypes.h>. Unlike the support for binary integers with 0b or 0B prefix with scanf %i, this is supported in all versions of scanf (independent of the standards mode used for compilation), because there are no backwards compatibility concerns (%b wasn't previously a supported format) the way there were for %i. Tested for x86_64 and x86.
* stdlib: Tune down fork arc4random testsAdhemerval Zanella Netto2023-06-121-8/+4
| | | | | | | | | There is no fork detection on current arc4random implementation, so use lower subprocess on fork tests. The tests now run on 0.1s instead of 8s on a Ryzen9 5900X. Checked on x86_64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* tests: Replace various function calls with their x variantFrédéric Bérat2023-06-061-1/+3
| | | | | | | With fortification enabled, few function calls return result need to be checked, has they get the __wur macro enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Fix a few more typos I missed in previous round -- BZ 25337Paul Pluzhnikov2023-06-021-1/+1
|
* Fix all the remaining misspellings -- BZ 25337Paul Pluzhnikov2023-06-028-10/+10
|
* tests: fix warn unused resultsFrédéric Bérat2023-06-011-3/+13
| | | | | | With fortification enabled, few function calls return result need to be checked, has they get the __wur macro enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Fix special case for C2x strtol binary constant handling (BZ# 30371)Adhemerval Zanella2023-05-256-39/+61
| | | | | | | | | | When the base is 0 or 2 and the first two characters are '0' and 'b', but the rest are no binary digits. In this case this is no error, and strtol must return 0 and ENDPTR points to the 'x' or 'b'. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* stdlib: Avoid undefined behavior in stdlib/tst-labsFlorian Weimer2023-05-171-12/+13
| | | | | | | | | The last loop could attempt to overflow beyond INT_MAX on 32-bit architectures. Also switch to GNU style. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* stdlib: Use long long int in stdlib/tst-llabsFlorian Weimer2023-05-171-15/+15
| | | | | | And adjust for GNU style. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* stdlib: Add testcases for llabs(). (BZ #30263)Joe Simmons-Talbott2023-05-162-0/+57
| | | | | | | | Test minimum and maximum long long values, zero, 32bit crossover points, and part of the range of long long values. Use '-fno-builtin' to ensure we are testing the implementation. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* stdlib: Add testcases for labs(). (BZ #30263)Joe Simmons-Talbott2023-05-162-0/+53
| | | | | | | | Test minimum and maximum long values, zero, and part of the range of long values. Use '-fno-builtin' to ensure we are testing the implementation. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* stdlib: Add testcases for abs(). (BZ #30263)Joe Simmons-Talbott2023-05-162-0/+48
| | | | | | | | Test minimum and maximum int values, zero, and part of the range of int values. Use '-fno-builtin' to ensure we are testing the implementation. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* stdlib: Reformat Makefile.Carlos O'Donell2023-05-161-3/+3
| | | | | | | | Reflow Makefile. Sort using scripts/sort-makefile-lines.py. No code generation changes observed in binary artifacts. No regressions on x86_64 and i686.
* testsuite: stdlib/isomac.c: fix REQUIREMENTSнаб2023-05-081-7/+4
| | | | | | | | | All of the mentioned variables are gone. gcc is just the default and argv[1] can be used instead. /usr/include isn't hard-coded and you can pass argv[2] with -I... to adjust. Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* system: Add "--" after "-c" for sh (BZ #28519)Joe Simmons-Talbott2023-03-281-0/+14
| | | | | | | | | | | Prevent sh from interpreting a user string as shell options if it starts with '-' or '+'. Since the version of /bin/sh used for testing system() is different from the full-fledged system /bin/sh add support to it for handling "--" after "-c". Add a testcase to ensure the expected behavior. Signed-off-by: Joe Simmons-Talbott <josimmon@redhat.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Move libc_freeres_ptrs and libc_subfreeres to hidden/weak functionsAdhemerval Zanella Netto2023-03-273-3/+5
| | | | | | | | | | | | | | | | | | | | They are both used by __libc_freeres to free all library malloc allocated resources to help tooling like mtrace or valgrind with memory leak tracking. The current scheme uses assembly markers and linker script entries to consolidate the free routine function pointers in the RELRO segment and to be freed buffers in BSS. This patch changes it to use specific free functions for libc_freeres_ptrs buffers and call the function pointer array directly with call_function_static_weak. It allows the removal of both the internal macros and the linker script sections. Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Update printf %b/%B C2x supportJoseph Myers2023-03-141-0/+39
| | | | | | | | | | | | | | | | WG14 recently accepted two additions to the printf/scanf %b/%B support: there are now PRIb* and SCNb* macros in <inttypes.h>, and printf %B is now an optional feature defined in normative text, instead of recommended practice, with corresponding PRIB* macros that can also be used to test whether that optional feature is supported. See N3072 items 14 and 15 for details (those changes were accepted, some other changes in that paper weren't). Add the corresponding PRI* macros to glibc and update one place in the manual referring to %B as recommended. (SCNb* should naturally be added at the same time as the corresponding scanf %b support.) Tested for x86_64 and x86.
* hurd: fix build of tst-system.cAdam Yi2023-03-081-0/+1
| | | | | | | | | | | | We made tst-system.c depend on pthread, but that requires linking with $(shared-thread-library). It does not fail under Linux because the variable expands to nothing under Linux, but it fails for Hurd. I tested verified via cross-compiling that "make check" now works for Hurd. Signed-off-by: Adam Yi <ayi@janestreet.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* posix: Fix system blocks SIGCHLD erroneously [BZ #30163]Adam Yi2023-03-071-0/+26
| | | | | | | | | | | | | | | | | | | | | Fix bug that SIGCHLD is erroneously blocked forever in the following scenario: 1. Thread A calls system but hasn't returned yet 2. Thread B calls another system but returns SIGCHLD would be blocked forever in thread B after its system() returns, even after the system() in thread A returns. Although POSIX does not require, glibc system implementation aims to be thread and cancellation safe. This bug was introduced in 5fb7fc96350575c9adb1316833e48ca11553be49 when we moved reverting signal mask to happen when the last concurrently running system returns, despite that signal mask is per thread. This commit reverts this logic and adds a test. Signed-off-by: Adam Yi <ayi@janestreet.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdlib: Undo post review change to 16adc58e73f3 [BZ #27749]Vitaly Buka2023-02-203-2/+81
| | | | | | | | | | Post review removal of "goto restart" from https://sourceware.org/pipermail/libc-alpha/2021-April/125470.html introduced a bug when some atexit handers skipped. Signed-off-by: Vitaly Buka <vitalybuka@google.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Use uintptr_t instead of performing pointer subtraction with a null pointerQihao Chencao2023-02-171-3/+3
| | | | | | Signed-off-by: Qihao Chencao <twose@qq.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdlib: Simplify getenvAdhemerval Zanella2023-02-171-59/+5
| | | | | | | | And remove _STRING_ARCH_unaligned usage. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* C2x strtol binary constant handlingJoseph Myers2023-02-1618-10/+523
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C2x adds binary integer constants starting with 0b or 0B, and supports those constants in strtol-family functions when the base passed is 0 or 2. Implement that strtol support for glibc. As discussed at <https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>, this is incompatible with previous C standard versions, in that such an input string starting with 0b or 0B was previously required to be parsed as 0 (with the rest of the string unprocessed). Thus, as proposed there, this patch adds 20 new __isoc23_* functions with appropriate header redirection support. This patch does *not* do anything about scanf %i (which will need 12 new functions per long double variant, so 12, 24 or 36 depending on the glibc configuration), instead leaving that for a future patch. The function names would remain as __isoc23_* even if C2x ends up published in 2024 rather than 2023. Making this change leads to the question of what should happen to internal uses of these functions in glibc and its tests. The header redirection (which applies for _GNU_SOURCE or any other feature test macros enabling C2x features) has the effect of redirecting internal uses but without those uses then ending up at a hidden alias (see the comment in include/stdio.h about interaction with libc_hidden_proto). It seems desirable for the default for internal uses to be the same versions used by normal code using _GNU_SOURCE, so rather than doing anything to disable that redirection, similar macro definitions to those in include/stdio.h are added to the include/ headers for the new functions. Given that the default for uses in glibc is for the redirections to apply, the next question is whether the C2x semantics are correct for all those uses. Uses with the base fixed to 10, 16 or any other value other than 0 or 2 can be ignored. I think this leaves the following internal uses to consider (an important consideration for review of this patch will be both whether this list is complete and whether my conclusions on all entries in it are correct): benchtests/bench-malloc-simple.c benchtests/bench-string.h elf/sotruss-lib.c math/libm-test-support.c nptl/perf.c nscd/nscd_conf.c nss/nss_files/files-parse.c posix/tst-fnmatch.c posix/wordexp.c resolv/inet_addr.c rt/tst-mqueue7.c soft-fp/testit.c stdlib/fmtmsg.c support/support_test_main.c support/test-container.c sysdeps/pthread/tst-mutex10.c I think all of these places are OK with the new semantics, except for resolv/inet_addr.c, where the POSIX semantics of inet_addr do not allow for binary constants; thus, I changed that file (to use __strtoul_internal, whose semantics are unchanged) and added a test for this case. In the case of posix/wordexp.c I think accepting binary constants is OK since POSIX explicitly allows additional forms of shell arithmetic expressions, and in stdlib/fmtmsg.c SEV_LEVEL is not in POSIX so again I think accepting binary constants is OK. Functions such as __strtol_internal, which are only exported for compatibility with old binaries from when those were used in inline functions in headers, have unchanged semantics; the __*_l_internal versions (purely internal to libc and not exported) have a new argument to specify whether to accept binary constants. As well as for the standard functions, the header redirection also applies to the *_l versions (GNU extensions), and to legacy functions such as strtoq, to avoid confusing inconsistency (the *q functions redirect to __isoc23_*ll rather than needing their own __isoc23_* entry points). For the functions that are only declared with _GNU_SOURCE, this means the old versions are no longer available for normal user programs at all. An internal __GLIBC_USE_C2X_STRTOL macro is used to control the redirections in the headers, and cases in glibc that wish to avoid the redirections - the function implementations themselves and the tests of the old versions of the GNU functions - then undefine and redefine that macro to allow the old versions to be accessed. (There would of course be greater complexity should we wish to make any of the old versions into compat symbols / avoid them being defined at all for new glibc ABIs.) strtol_l.c has some similarity to strtol.c in gnulib, but has already diverged some way (and isn't listed at all at https://sourceware.org/glibc/wiki/SharedSourceFiles unlike strtoll.c and strtoul.c); I haven't made any attempts at gnulib compatibility in the changes to that file. I note incidentally that inttypes.h and wchar.h are missing the __nonnull present on declarations of this family of functions in stdlib.h; I didn't make any changes in that regard for the new declarations added.
* Replace rawmemchr (s, '\0') with strchrWilco Dijkstra2023-02-061-2/+1
| | | | | | | | | Almost all uses of rawmemchr find the end of a string. Since most targets use a generic implementation, replacing it with strchr is better since that is optimized by compilers into strlen (s) + s. Also fix the generic rawmemchr implementation to use a cast to unsigned char in the if statement. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdlib: tests: don't double-define _FORTIFY_SOURCESam James2023-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | If using -D_FORITFY_SOURCE=3 (in my case, I've patched GCC to add =3 instead of =2 (we've done =2 for years in Gentoo)), building glibc tests will fail on testmb like: ``` <command-line>: error: "_FORTIFY_SOURCE" redefined [-Werror] <built-in>: note: this is the location of the previous definition cc1: all warnings being treated as errors make[2]: *** [../o-iterator.mk:9: /var/tmp/portage/sys-libs/glibc-2.36/work/build-x86-x86_64-pc-linux-gnu-nptl/stdlib/testmb.o] Error 1 make[2]: *** Waiting for unfinished jobs.... ``` It's just because we're always setting -D_FORTIFY_SOURCE=2 rather than unsetting it first. If F_S is already 2, it's harmless, but if it's another value (say, 1, or 3), the compiler will bawk. (I'm not aware of a reason this couldn't be tested with =3, but the toolchain support is limited for that (too new), and we want to run the tests everywhere possible.) Signed-off-by: Sam James <sam@gentoo.org> Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-03 10:54:50 +0000