Fix multiple memory leaks in the locale program:
1. PUT (xstrdup (...)) leaks when tsearch finds a duplicate entry,
since tsearch returns the existing node and the newly allocated
string is orphaned. Introduce PUT_UNIQUE, which looks the name up
with GET first and only allocates when it is actually inserted.
2. String literals "POSIX" and "C" passed to PUT cannot be freed by
tdestroy. They now go through PUT_UNIQUE, which duplicates them,
so tdestroy (all_data, free) is safe.
3. Add tdestroy (all_data, free) at the end of write_locales and
write_charmaps to free the search trees.
4. Free dirents[cnt] entries in the scandir loop (only the dirents
array pointer was freed, not the individual entries).
5. Free alias_path allocated by argz_create_sep in write_locales.
Before this change "locale -a" leaked 74 bytes in 3 blocks directly
and 835 bytes in 49 blocks indirectly, and "locale -m" leaked 2190
bytes in 227 blocks. Both are valgrind-clean afterwards.
These leaks were reported by Arjun Shankar via GCC -fanalyzer
(OpenScanHub/Fedora).
Resolves: BZ #33972
Signed-off-by: Ruslan Valiyev <linuxoid@gmail.com>
Reviewed-by: Arjun Shankar <arjun@redhat.com>
Add locale data for Brahui (brh), a Dravidian language spoken by
approximately 2.8 million people (2023 Pakistan Census) primarily in
Balochistan, Pakistan. Brahui is the only Dravidian language written
in the Perso-Arabic (Nastaliq) script.
The ISO 639-3 code brh is added to iso-639.def. Brahui has no ISO
639-1 or ISO 639-2 code, so the three-letter code is used for both the
terminology and bibliographic fields, as is already done for other
639-3-only entries such as brx (Bodo).
Locale content follows CLDR locale brh, for which the submitter is the
contributing native speaker.
Changes since v3:
- iso-639.def: place Brahui before Braj, restoring alphabetical
order by English language name.
- LC_TIME: add first_weekday 1 and first_workday 2. The previous
value of 7 selected Saturday, which does not match CLDR territory
data for PK (firstDay = sun); ur_PK and sd_PK both use 1.
- LC_TIME: reorder d_t_fmt and date_fmt so the date precedes the
time, matching the CLDR brh date-time combination pattern and the
shape used by sd_PK, and use U+060C ARABIC COMMA as the separator,
which is the comma in the CLDR brh punctuation exemplar set.
- LC_TIME: abday repeats the full day names, as Brahui has no
distinct abbreviated forms; CLDR brh gives identical values at the
abbreviated and wide widths, and ur_PK, pa_PK and fa_IR do the
same.
- LC_TIME: am_pm now matches the CLDR brh day-period values.
- LC_MONETARY: n_sep_by_space 1, matching p_sep_by_space, so that
positive and negative amounts are spaced alike.
- LC_MESSAGES: yesexpr accepts U+062C and U+0647, and noexpr accepts
U+0627, since these initials occur in attested spellings of the
affirmative and negative words.
- LC_CTYPE: add transliterations for U+06C1 and U+06B7.
- LC_TELEPHONE: use the "+%c %a %l" form.
- LC_IDENTIFICATION: record CLDR as the source; bump revision.
Signed-off-by: Hammad Mengal <hammadalo99@gmail.com>
Reviewed-by: Mike FABIAN <mfabian@redhat.com>
It is a fix for memory leak in the function 'newlocale' (the real name is __newlocale).
There is not released a memory for the local buffer 'locale_path'.
https://sourceware.org/bugzilla/show_bug.cgi?id=25770
---
Patch was tested on Ubuntu 24.04.
My 'LOCPATH' environment variable is "/snap/code/193/usr/lib/locale".
With an original (system) libc I have the following problem:
#0 0x7d5c3aafc778 in realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:85
#1 0x7d5c394b05f2 in __argz_add_sep string/argz-addsep.c:34
#2 0x7d5c39439bdb in __newlocale locale/newlocale.c:111
#3 0x7d5c370e58fc (/lib/x86_64-linux-gnu/libp11-kit.so.0+0x1098fc) (BuildId: 1cbcd6ac7e0ff0259eb3acc14d556d2c1ec00cdc)
#4 0x7d5c3b14571e in call_init elf/dl-init.c:74
#5 0x7d5c3b145823 in call_init elf/dl-init.c:120
#6 0x7d5c3b145823 in _dl_init elf/dl-init.c:121
#7 0x7d5c3b15f59f (/lib64/ld-linux-x86-64.so.2+0x1f59f) (BuildId: 1c8db5f83bba514f8fd5f1fb6d7be975be1bb855)
SUMMARY: AddressSanitizer: 46 byte(s) leaked in 1 allocation(s).
When I run with my corrected libc, through runtest.sh <my-application>, all is OK.
Signed-off-by: Dmitry Kovalenko <d.kovalenko@postgrespro.ru>
Co-authored-by: Florian Weimer <fweimer@redhat.com>
In commit 970364dac0 we switched some
/*FALLTHROUGH*/ comments to [[fallthrough]] to avoid warnings with
Clang. However, since gperf emitted different output the buildbot
failed. The buildbot has been updated to use gperf 3.3 which will use
__attribute__ ((__fallthrough__)) where needed to avoid warnings [1].
This patch regenerates these files with the same version.
[1] https://sourceware.org/pipermail/libc-testresults/2025q4/014123.html
Reviewed-by: Mark Wielaard <mark@klomp.org>
The clang default to warning for missing fall-through and it does
not support all comment-like annotation that gcc does. Use C23
[[fallthrough]] annotation instead.
proper attribute instead.
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
On x86-64, when GCC 14.2.1 is used to build:
commit f3c82fc1b4
Author: Radko Krkos <krkos@mail.muni.cz>
Date: Sat Jun 14 11:07:40 2025 +0200
io: Mark lockf() __wur [BZ #32800]
In commit 0476597b28 flock() was marked __wur in posix/unistd.h, but not
in io/fcntl.h, the declarations must match.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
I got
programs/locarchive.c: In function ‘open_archive’:
programs/locarchive.c:641:18: error: ignoring return value of ‘lockf64’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
641 | (void) lockf64 (fd, F_ULOCK, sizeof (struct locarhead));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
programs/locarchive.c:653:14: error: ignoring return value of ‘lockf64’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
653 | (void) lockf64 (fd, F_ULOCK, sizeof (struct locarhead));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
programs/locarchive.c:660:14: error: ignoring return value of ‘lockf64’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
660 | (void) lockf64 (fd, F_ULOCK, sizeof (struct locarhead));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
programs/locarchive.c:679:14: error: ignoring return value of ‘lockf64’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
679 | (void) lockf64 (fd, F_ULOCK, sizeof (struct locarhead));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Update locarchive.c to always check lockf64 return value. This fixes
BZ #33089.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
These variables are not exported, and libc.so TLS is initial-exec
anyway. Declare these variables as hidden and use the initial-exec
TLS model.
Reviewed-by: Frédéric Bérat <fberat@redhat.com>
Use __thread variables directly instead. The macros do not save any
typing. It seems unlikely that a future port will lack __thread
variable support.
Some of the __libc_tsd_* variables are referenced from assembler
files, so keep their names. Previously, <libc-tls.h> included
<tls.h>, which in turn included <errno.h>, so a few direct includes
of <errno.h> are now required.
Reviewed-by: Frédéric Bérat <fberat@redhat.com>
I've updated copyright dates in glibc for 2025. This is the patch for
the changes not generated by scripts/update-copyrights and subsequent
build / regeneration of generated files.
Fix variables in Makefiles:
1. There is a tab, not a space, between "variable" and =, +=, :=.
2. The last entry doesn't have a trailing \.
and sort them.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Macros will automatically use the correct types, without
having to fiddle with internal glibc macros. It's also
impossible to get the types wrong due to aliasing because
support_check_stat_fd and support_check_stat_path do not
depend on the struct stat* types.
The changes reveal some inconsistencies in tests.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Delay setting file->decided until the data has been successfully loaded
by _nl_load_locale(). If the function fails to load the data then we
must return and error and leave decided untouched to allow the caller to
attempt to load the data again at a later time. We should not set
decided to 1 early in the function since doing so may prevent attempting
to load it again. We want to try loading it again because that allows an
open to fail and set errno correctly.
On the other side of this problem is that if we are called again with
the same inputs we will fetch the cached version of the object and carry
out no open syscalls and that fails to set errno so we must set errno to
ENOENT in that case. There is a second code path that has to be handled
where the name of the locale matches but the codeset doesn't match.
These changes ensure that errno is correctly set on failure in all the
return paths in _nl_find_locale().
Adds tst-locale-loadlocale to cover the bug.
No regressions on x86_64.
Co-authored-by: Jeff Law <law@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Protect the global locale from being modified while we compute the size of
the locale category names. That allows the use of the global locale in a
single thread, while all other threads use the thread safe locale
functions.
I've updated copyright dates in glibc for 2024. This is the patch for
the changes not generated by scripts/update-copyrights and subsequent
build / regeneration of generated files.
All the crypt related functions, cryptographic algorithms, and
make requirements are removed, with only the exception of md5
implementation which is moved to locale folder since it is
required by localedef for integrity protection (libc's
locale-reading code does not check these, but localedef does
generate them).
Besides thec code itself, both internal documentation and the
manual is also adjusted. This allows to remove both --enable-crypt
and --enable-nss-crypt configure options.
Checked with a build for all affected ABIs.
Co-authored-by: Zack Weinberg <zack@owlfolio.org>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Since asprintf is called "if (mask & XPG_NORM_CODESET)" there is no
point in checking the mask again within the asprintf call.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
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>
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.
The buffer used by snprintf might not be large enough for all possible
inputs, as indicated by gcc with -O1:
../locale/programs/linereader.c: In function ‘utf8_sequence_error’:
../locale/programs/linereader.c:713:58: error: ‘%02x’ directive output
may be truncated writing between 2 and 8 bytes into a region of size
between 1 and 13 [-Werror=format-truncation=]
713 | snprintf (buf, sizeof (buf), "0x%02x 0x%02x 0x%02x 0x%02x",
| ^~~~
../locale/programs/linereader.c:713:34: note: directive argument in the
range [0, 2147483647]
713 | snprintf (buf, sizeof (buf), "0x%02x 0x%02x 0x%02x 0x%02x",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../locale/programs/linereader.c:713:5: note: ‘snprintf’ output between
20 and 38 bytes into a destination of size 30
713 | snprintf (buf, sizeof (buf), "0x%02x 0x%02x 0x%02x 0x%02x",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
714 | ch1, ch2, ch3, ch4);
| ~~~~~~~~~~~~~~~~~~~
Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
I've updated copyright dates in glibc for 2023. This is the patch for
the changes not generated by scripts/update-copyrights and subsequent
build / regeneration of generated files.
For some reason this causes a pre-commit check error for a copyright
date update commit, even though that commit doesn't touch anything
near the line with this whitespace.
Fixes following error when building with -Os:
| In file included from strcoll_l.c:43:
| strcoll_l.c: In function '__strcoll_l':
| ../locale/weight.h:31:26: error: 'seq2.back_us' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
| int_fast32_t i = table[*(*cpp)++];
| ^~~~~~~~~
| strcoll_l.c:304:18: note: 'seq2.back_us' was declared here
| coll_seq seq1, seq2;
| ^~~~
| In file included from strcoll_l.c:43:
| ../locale/weight.h:31:26: error: 'seq1.back_us' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
| int_fast32_t i = table[*(*cpp)++];
| ^~~~~~~~~
| strcoll_l.c:304:12: note: 'seq1.back_us' was declared here
| coll_seq seq1, seq2;
| ^~~~
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
The Z modifier is a nonstandard synonymn for z (that predates z
itself) and compiler might issue an warning for in invalid
conversion specifier.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The locale generation are issues in parallel to try speed locale
generation. The maximum number of jobs are limited to the online
CPU (in hope to not overcommit on environments with lower cores
than tests).
On a Ryzen 9, the test execution improves from ~6.7s to ~1.4s.
Tested-by: Mark Wielaard <mark@klomp.org>
Previously, they were assumed to be in ISO-8859-1, and that the output
charset overlapped with ISO-8859-1 for the characters actually used.
However, this did not work as intended on many architectures even for
an ISO-8859-1 output encoding because of the char signedness bug in
lr_getc. Therefore, this commit switches to UTF-8 without making
provisions for backwards compatibility.
The following Elisp code can be used to convert locale definition files
to UTF-8:
(defun glibc/convert-localedef (from to)
(interactive "r")
(save-excursion
(save-restriction
(narrow-to-region from to)
(goto-char (point-min))
(save-match-data
(while (re-search-forward "<U\\([0-9a-fA-F]+\\)>" nil t)
(let* ((codepoint (string-to-number (match-string 1) 16))
(converted
(cond
((memq codepoint '(?/ ?\ ?< ?>))
(string ?/ codepoint))
((= codepoint ?\") "<U0022>")
(t (string codepoint)))))
(replace-match converted t)))))))
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
This will permit reusing the Unicode character processing for
different character encodings, not just the current <U...> encoding.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
Ruslan Valiyev