aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-01-09i386: Remove CET supportAdhemerval Zanella31-770/+75
CET is only support for x86_64, this patch reverts: - faaee1f07ed x86: Support shadow stack pointer in setjmp/longjmp. - be9ccd27c09 i386: Add _CET_ENDBR to indirect jump targets in add_n.S/sub_n.S - c02695d7764 x86/CET: Update vfork to prevent child return - 5d844e1b725 i386: Enable CET support in ucontext functions - 124bcde683 x86: Add _CET_ENDBR to functions in crti.S - 562837c002 x86: Add _CET_ENDBR to functions in dl-tlsdesc.S - f753fa7dea x86: Support IBT and SHSTK in Intel CET [BZ #21598] - 825b58f3fb i386-mcount.S: Add _CET_ENDBR to _mcount and __fentry__ - 7e119cd582 i386: Use _CET_NOTRACK in i686/memcmp.S - 177824e232 i386: Use _CET_NOTRACK in memcmp-sse4.S - 0a899af097 i386: Use _CET_NOTRACK in memcpy-ssse3-rep.S - 7fb613361c i386: Use _CET_NOTRACK in memcpy-ssse3.S - 77a8ae0948 i386: Use _CET_NOTRACK in memset-sse2-rep.S - 00e7b76a8f i386: Use _CET_NOTRACK in memset-sse2.S - 90d15dc577 i386: Use _CET_NOTRACK in strcat-sse2.S - f1574581c7 i386: Use _CET_NOTRACK in strcpy-sse2.S - 4031d7484a i386/sub_n.S: Add a missing _CET_ENDBR to indirect jump - target - Checked on i686-linux-gnu.
2024-01-09x86: Move CET infrastructure to x86_64Adhemerval Zanella62-265/+270
The CET is only supported for x86_64 and there is no plan to add kernel support for i386. Move the Makefile rules and files from the generic x86 folder to x86_64 one. Checked on x86_64-linux-gnu and i686-linux-gnu.
2024-01-09localedata: su_ID: make lang_name agree with CLDRMike FABIAN1-1/+1
2024-01-09localedata: add new locale su_IDMike FABIAN2-0/+165
Resolves: BZ # 27312
2024-01-09localedata: add new locale zgh_MAMike FABIAN3-0/+192
Resolves: BZ # 12908 https://iso639-3.sil.org/code/zgh
2024-01-09INSTALL: regenerateMark Wielaard1-7/+7
2024-01-09localedata: add tok/UTF-8 to SUPPORTEDMike FABIAN1-0/+1
2024-01-09localedata: tok: add yY and nN to yesexpr and noexprMike FABIAN1-2/+2
See: https://sourceware.org/bugzilla/show_bug.cgi?id=31221#c2
2024-01-09localedata: tok: convert to UTF-8Mike FABIAN1-3/+3
2024-01-09localedata: add data for tok (Toki Pona)Janet Blackquill1-0/+154
Resolves: BZ # 31221 glibc can recognise its code, but does not have its data. This patch remedies that. Signed-off-by: Janet Blackquill <uhhadd@gmail.com>
2024-01-08Remove ia64-linux-gnuAdhemerval Zanella567-155609/+39
Linux 6.7 removed ia64 from the official tree [1], following the general principle that a glibc port needs upstream support for the architecture in all the components it depends on (binutils, GCC, and the Linux kernel). Apart from the removal of sysdeps/ia64 and sysdeps/unix/sysv/linux/ia64, there are updates to various comments referencing ia64 for which removal of those references seemed appropriate. The configuration is removed from README and build-many-glibcs.py. The CONTRIBUTED-BY, elf/elf.h, manual/contrib.texi (the porting mention), *.po files, config.guess, and longlong.h are not changed. For Linux it allows cleanup some clone2 support on multiple files. The following bug can be closed as WONTFIX: BZ 22634 [2], BZ 14250 [3], BZ 21634 [4], BZ 10163 [5], BZ 16401 [6], and BZ 11585 [7]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ff221426d33db909f7159fdf620c3b052e2d1c [2] https://sourceware.org/bugzilla/show_bug.cgi?id=22634 [3] https://sourceware.org/bugzilla/show_bug.cgi?id=14250 [4] https://sourceware.org/bugzilla/show_bug.cgi?id=21634 [5] https://sourceware.org/bugzilla/show_bug.cgi?id=10163 [6] https://sourceware.org/bugzilla/show_bug.cgi?id=16401 [7] https://sourceware.org/bugzilla/show_bug.cgi?id=11585 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2024-01-08localedata: dz_BT, bo_CN: convert to UTF-8Mike FABIAN2-136/+136
2024-01-08localedata: dz_BT, bo_CN: Fix spelling of "phur bu" in both Tibetan and DzongkhaValery Ushakov2-4/+4
Resolves: BZ # 31086
2024-01-08localedata: bo_CN: Fix spelling errors in Tibetan dataValery Ushakov1-20/+23
Resolves: BZ # 31086
2024-01-08localedata: bo_CN: Fix incomplete edit in Tibetan yesexprValery Ushakov1-1/+1
Resolves: BZ # 31086
2024-01-08localedata: dz_BT: Fix spelling errors in Dzongha dataValery Ushakov1-23/+23
Resolves: BZ # 31086
2024-01-08localedata: unicode-gen: Remove redundant \s* from regexp, fix commentsMike FABIAN2-5/+5
2024-01-08localedata: convert the remaining *_RU locales to UTF-8Mike FABIAN6-264/+264
2024-01-07Incorporate translationsAndreas K. Hüttel38-5109/+5428
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2024-01-06x32: Handle displacement overflow in PLT rewrite [BZ #31218]H.J. Lu4-2/+89
PLT rewrite calculated displacement with ElfW(Addr) disp = value - branch_start - JMP32_INSN_SIZE; On x32, displacement from 0xf7fbe060 to 0x401030 was calculated as unsigned int disp = 0x401030 - 0xf7fbe060 - 5; with disp == 0x8442fcb and caused displacement overflow. The PLT entry was changed to: 0xf7fbe060 <+0>: e9 cb 2f 44 08 jmp 0x401030 0xf7fbe065 <+5>: cc int3 0xf7fbe066 <+6>: cc int3 0xf7fbe067 <+7>: cc int3 0xf7fbe068 <+8>: cc int3 0xf7fbe069 <+9>: cc int3 0xf7fbe06a <+10>: cc int3 0xf7fbe06b <+11>: cc int3 0xf7fbe06c <+12>: cc int3 0xf7fbe06d <+13>: cc int3 0xf7fbe06e <+14>: cc int3 0xf7fbe06f <+15>: cc int3 x32 has 32-bit address range, but it doesn't wrap address around at 4GB, JMP target was changed to 0x100401030 (0xf7fbe060LL + 0x8442fcbLL + 5), which is above 4GB. Always use uint64_t to calculate displacement. This fixes BZ #31218. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
2024-01-05x86: Fixup some nits in longjmp asm implementationNoah Goldstein1-1/+1
Replace a stray `nop` with a `.p2align` directive.
2024-01-05stdlib: Fix stdbit.h with -Wconversion for clangAdhemerval Zanella1-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.
2024-01-05stdlib: Fix stdbit.h with -Wconversion for older gccAdhemerval Zanella1-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.
2024-01-05elf: Add ELF_DYNAMIC_AFTER_RELOC to rewrite PLTH.J. Lu17-2/+451
Add ELF_DYNAMIC_AFTER_RELOC to allow target specific processing after relocation. For x86-64, add #define DT_X86_64_PLT (DT_LOPROC + 0) #define DT_X86_64_PLTSZ (DT_LOPROC + 1) #define DT_X86_64_PLTENT (DT_LOPROC + 3) 1. DT_X86_64_PLT: The address of the procedure linkage table. 2. DT_X86_64_PLTSZ: The total size, in bytes, of the procedure linkage table. 3. DT_X86_64_PLTENT: The size, in bytes, of a procedure linkage table entry. With the r_addend field of the R_X86_64_JUMP_SLOT relocation set to the memory offset of the indirect branch instruction. Define ELF_DYNAMIC_AFTER_RELOC for x86-64 to rewrite the PLT section with direct branch after relocation when the lazy binding is disabled. PLT rewrite is disabled by default since SELinux may disallow modifying code pages and ld.so can't detect it in all cases. Use $ export GLIBC_TUNABLES=glibc.cpu.plt_rewrite=1 to enable PLT rewrite with 32-bit direct jump at run-time or $ export GLIBC_TUNABLES=glibc.cpu.plt_rewrite=2 to enable PLT rewrite with 32-bit direct jump and on APX processors with 64-bit absolute jump at run-time. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
2024-01-04aarch64: Make cpu-features definitions not Linux-specificSergey Bugaev2-0/+0
These describe generic AArch64 CPU features, and are not tied to a kernel-specific way of determining them. We can share them between the Linux and Hurd AArch64 ports. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240103171502.1358371-13-bugaevc@gmail.com>
2024-01-04hurd: Initializy _dl_pagesize early in static buildsSergey Bugaev1-0/+4
We fetch __vm_page_size as the very first RPC that we do, inside __mach_init (). Propagate that to _dl_pagesize ASAP after that, before any other initialization. In dynamic builds, this is already done immediately after __mach_init (), inside _dl_sysdep_start (). Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240103171502.1358371-12-bugaevc@gmail.com>
2024-01-04hurd: Only init early static TLS if it's used to store stack or pointer guardsSergey Bugaev1-4/+11
This is the case on both x86 architectures, but not on AArch64. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240103171502.1358371-11-bugaevc@gmail.com>
2024-01-04hurd: Make init-first.c no longer x86-specificSergey Bugaev1-2/+2
This will make it usable in other ports. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240103171502.1358371-10-bugaevc@gmail.com>
2024-01-04hurd: Drop x86-specific assembly from init-first.cSergey Bugaev1-9/+1
We already have the RETURN_TO macro for this exact use case, and it's already used in the non-static code path. Use it here too. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240103171502.1358371-9-bugaevc@gmail.com>
2024-01-04hurd: Pass the data pointer to _hurd_stack_setup explicitlySergey Bugaev3-9/+11
Instead of relying on the stack frame layout to figure out where the stack pointer was prior to the _hurd_stack_setup () call, just pass the pointer as an argument explicitly. This is less brittle and much more portable. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-ID: <20240103171502.1358371-8-bugaevc@gmail.com>
2024-01-04x86-64/cet: Check the restore token in longjmpH.J. Lu3-145/+84
setcontext and swapcontext put a restore token on the old shadow stack which is used to restore the target shadow stack when switching user contexts. When longjmp from a user context, the target shadow stack can be different from the current shadow stack and INCSSP can't be used to restore the shadow stack pointer to the target shadow stack. Update longjmp to search for a restore token. If found, use the token to restore the shadow stack pointer before using INCSSP to pop the shadow stack. Stop the token search and use INCSSP if the shadow stack entry value is the same as the current shadow stack pointer. It is a user error if there is a shadow stack switch without leaving a restore token on the old shadow stack. The only difference between __longjmp.S and __longjmp_chk.S is that __longjmp_chk.S has a check for invalid longjmp usages. Merge __longjmp.S and __longjmp_chk.S by adding the CHECK_INVALID_LONGJMP macro. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
2024-01-04localedata: ru_RU, ru_UA: convert to UTF-8Mike FABIAN2-75/+75
2024-01-04localedata: es_??: convert to UTF-8Mike FABIAN20-114/+114
2024-01-04localedata: miq_NI: convert to UTF-8Mike FABIAN1-7/+7
2024-01-04i386: Ignore --enable-cetH.J. Lu9-131/+137
Since shadow stack is only supported for x86-64, ignore --enable-cet for i386. Always setting $(enable-cet) for i386 to "no" to support ifneq ($(enable-cet),no) in x86 Makefiles. We can't use ifeq ($(enable-cet),yes) since $(enable-cet) can be "yes", "no" or "permissive". Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2024-01-03mach: Drop SNARF_ARGS macroSergey Bugaev2-21/+0
We're obtaining arguments from the stack differently, see init-first.c. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2024-01-03mach: Drop some unnecessary vm_param.h includesSergey Bugaev2-2/+0
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2024-01-03hurd: Declare _hurd_intr_rpc_msg* with protected visibilitySergey Bugaev1-3/+3
These symbols are internal and never exported; make sure the compiler realizes that when compiling hurdsig.c and does not try to emit GOT reads. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2024-01-03hurd: Add some missing includesSergey Bugaev3-1/+3
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2024-01-03localedata: fy_DE: make this "Western Frisian" to agree with the language ↵Mike FABIAN1-29/+35
code "fy" Resolves: BZ # 14522
2024-01-03localedata: fy_DE, fy_NL: convert to UTF-8Mike FABIAN2-3/+3
2024-01-03localedata: ast_ES: convert to UTF-8Mike FABIAN1-9/+9
2024-01-03localedata: ast_ES: Remove wrong copyright textMike FABIAN1-3/+1
Resolves: BZ # 27601
2024-01-03localedata: de_{AT,BE,CH,IT,LU}: convert to UTF-8Mike FABIAN5-24/+24
2024-01-03localedata: lv_LV, it_IT, it_CH: convert to UTF-8Mike FABIAN3-33/+33
2024-01-03localedata: it_IT, lv_LV: currency symbol should follow the amountMike FABIAN2-6/+6
Resolves: BZ # 28558
2024-01-03Implement C23 <stdbit.h>Joseph Myers133-15/+7011
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.
2024-01-03localedata: ms_MY should not use 12-hour formatMike FABIAN1-7/+8
Resolves: BZ # 29504
2024-01-02localedata: es_ES: convert to UTF-8Mike FABIAN1-9/+9
2024-01-02localedata: es_ES: Add am_pm stringsMike FABIAN1-1/+1
Resolves: BZ # 24013 Use <U202F> instead of a plain space because CLDR also uses that.
generated by cgit v1.1 at 2025-03-06 08:55:15 +0000