glibc/bits, branch master

socket: Use may_alias on sockaddr structs (bug 19622)

2024-05-18T07:33:19Z

This supports common coding patterns. The GCC C front end before version 7 rejects the may_alias attribute on a struct definition if it was not present in a previous forward declaration, so this attribute can only be conditionally applied. This implements the spirit of the change in Austin Group issue 1641. Suggested-by: Marek Polacek Suggested-by: Jakub Jelinek Reviewed-by: Sam James Reviewed-by: Carlos O'Donell

login: Use unsigned 32-bit types for seconds-since-epoch

2024-04-19T12:38:17Z

These fields store timestamps when the system was running. No Linux systems existed before 1970, so these values are unused. Switching to unsigned types allows continued use of the existing struct layouts beyond the year 2038. The intent is to give distributions more time to switch to improved interfaces that also avoid locking/data corruption issues. Reviewed-by: Adhemerval Zanella

login: structs utmp, utmpx, lastlog _TIME_BITS independence (bug 30701)

2024-04-19T12:38:17Z

These structs describe file formats under /var/log, and should not depend on the definition of _TIME_BITS. This is achieved by defining __WORDSIZE_TIME64_COMPAT32 to 1 on 32-bit ports that support 32-bit time_t values (where __time_t is 32 bits). Reviewed-by: Adhemerval Zanella

Refer to C23 in place of C2X in glibc

2024-02-01T11:02:01Z

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.

Implement C23

2024-01-03T12:07:14Z

C23 adds a header 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 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.

Update copyright dates with scripts/update-copyrights

2024-01-01T18:53:40Z

linux: Add posix_spawnattr_{get, set}cgroup_np (BZ 26371)

2023-09-05T16:08:48Z

These functions allow to posix_spawn and posix_spawnp to use CLONE_INTO_CGROUP with clone3, allowing the child process to be created in a different cgroup version 2. These are GNU extensions that are available only for Linux, and also only for the architectures that implement clone3 wrapper (HAVE_CLONE3_WRAPPER). To create a process on a different cgroupv2, one can use the: posix_spawnattr_t attr; posix_spawnattr_init (&attr); posix_spawnattr_setflags (&attr, POSIX_SPAWN_SETCGROUP); posix_spawnattr_setcgroup_np (&attr, cgroup); posix_spawn (...) Similar to other posix_spawn flags, POSIX_SPAWN_SETCGROUP control whether the cgroup file descriptor will be used or not with clone3. There is no fallback if either clone3 does not support the flag or if the architecture does not provide the clone3 wrapper, in this case posix_spawn returns EOPNOTSUPP. Checked on x86_64-linux-gnu. Reviewed-by: Florian Weimer

Fix all the remaining misspellings -- BZ 25337

2023-06-02T01:39:48Z

Remap __GLIBC_FLT_EVAL_METHOD to 0 if __FLT_EVAL_METHOD__ is -1

2023-04-28T14:02:48Z

__GLIBC_FLT_EVAL_METHOD will effect the definition of float_t and double_t, currently we'll set __GLIBC_FLT_EVAL_METHOD to 2 when __FLT_EVAL_METHOD__ is -1, that means we'll define float_t and double_t to long double. However some target isn't natively (HW) support long double like AArch64 and RISC-V, they defined long double as 128-bits IEEE 754 floating point type. That means setting __GLIBC_FLT_EVAL_METHOD to 2 will cause very inefficient code gen for those target who didn't provide native support for long double, and that's violate the spirit float_t and double_t - most efficient types at least as wide as float and double. So this patch propose to remap __GLIBC_FLT_EVAL_METHOD to 0 rather than 2 when __FLT_EVAL_METHOD__ is -1, which means we'll use float/double rather than long double for float_t and double_t. Note: __FLT_EVAL_METHOD__ == -1 means the precision is indeterminable, which means compiler might using indeterminable precision during optimization/code gen, clang will set this value to -1 when fast math is enabled. Note: Default definition float_t and double_t in current glibc: | __GLIBC_FLT_EVAL_METHOD | float_t | double_t | 0 or 16 | float | double | 1 | double | doulbe | 2 | long double | long double More complete list see math/math.h Note: RISC-V has defined ISA extension to support 128-bits IEEE 754 floating point operations, but only rare RISC-V core will implement that. Related link: [1] LLVM issue (__FLT_EVAL_METHOD__ is set to -1 with Ofast. #60781): https://github.com/llvm/llvm-project/issues/60781 [2] Last version of this patch: https://sourceware.org/pipermail/libc-alpha/2023-February/145622.html Acked-by: Palmer Dabbelt # RISC-V Reviewed-by: Wilco Dijkstra Link: https://inbox.sourceware.org/libc-alpha/20230314151948.12892-1-kito.cheng@sifive.com Signed-off-by: Palmer Dabbelt

[hurd] Add MTU_DISCOVER values

2023-02-15T14:14:06Z