glibc

Commit Graph

Author	SHA1	Message	Date
Joseph Myers	83d8d289b2	Rename c2x / gnu2x tests to c23 / gnu23 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.	2 years ago
Joseph Myers	42cc619dfb	Refer to C23 in place of C2X in glibc 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.	2 years ago
Paul Eggert	dff8da6b3e	Update copyright dates with scripts/update-copyrights	2 years ago
Sunil K Pandey	b316c9a769	Add strlcat/wcslcat testcase. This patch implements comprehensive tests for strlcat/wcslcat functions. Tests are mostly derived from strncat test suites and modified to incorporate strlcat/wcslcat specifications. Reviewed-by: DJ Delorie <dj@redhat.com>	3 years ago
Sunil K Pandey	23871292fb	Add strlcpy/wcslcpy testcase This patch implements comprehensive tests for strlcpy/wcslcpy functions. Tests are mostly derived from strncpy test suites and modified to incorporate strlcpy/wcslcpy specifications. Reviewed-by: DJ Delorie <dj@redhat.com>	3 years ago
Joseph Myers	cdbf8229bb	C2x scanf %wN, %wfN support ISO C2x defines scanf length modifiers wN (for intN_t / int_leastN_t / uintN_t / uint_leastN_t) and wfN (for int_fastN_t / uint_fastN_t). Add support for those length modifiers, similar to the printf support previously added. Tested for x86_64 and x86.	3 years ago
Adhemerval Zanella	320ac7eeb4	vfscanf-internal: Remove potentially unbounded allocas Some locales define a list of mapping pairs of alternate digits and separators for input digits (to_inpunct). This require the scanf to create a list of all possible inputs for the optional type modifier 'I'. Checked on x86_64-linux-gnu. Reviewed-by: Joe Simmons-Talbott <josimmon@redhat.com>	3 years ago
Frédéric Bérat	64f9857507	wchar: Avoid PLT entries with _FORTIFY_SOURCE The change is meant to avoid unwanted PLT entries for the wmemset and wcrtomb routines when _FORTIFY_SOURCE is set. On top of that, ensure that *_chk routines have their hidden builtin definitions available. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>	3 years ago
Frédéric Bérat	20c894d21e	Exclude routines from fortification 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>	3 years ago
Frederic Berat	04d85febb9	wcsmbs/bits/wchar2{, -decl}.h: Clearly separate declaration from definitions This will enable __REDIRECT_FORTIFY* macros to be used when _FORTIFY_SOURCE is set. Routine declarations that were in bits/wchar2.h are moved into the bits/wchar2-decl.h file. The file is now included into include/wchar.h irrespectively from fortification. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>	3 years ago
Joseph Myers	5f83b2674e	C2x printf %wN, %wfN support (bug 24466) ISO C2x defines printf length modifiers wN (for intN_t / int_leastN_t / uintN_t / uint_leastN_t) and wfN (for int_fastN_t / uint_fastN_t). Add support for those length modifiers (such a feature was previously requested in bug 24466). scanf support is to be added separately. GCC 13 has format checking support for these modifiers. When used with the support for registering format specifiers, these modifiers are translated to existing flags in struct printf_info, rather than trying to add some way of distinguishing them without breaking the printf_info ABI. C2x requires an error to be returned for unsupported values of N; this is implemented for printf-family functions, but the parse_printf_format interface doesn't support error returns, so such an error gets discarded by that function. Tested for x86_64 and x86.	3 years ago
Florian Weimer	b54e5d1c92	Add the wcslcpy, wcslcat functions These functions are about to be added to POSIX, under Austin Group issue 986. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>	3 years ago
Paul Pluzhnikov	7f0d9e61f4	Fix all the remaining misspellings -- BZ 25337	3 years ago
Adhemerval Zanella	a363f70751	wchar: Define va_list for POSIX (BZ #30035 ) This was uncovered by a recent clang change [1]. Different than ISO C, POSIX states that va_list should be exported by wchar.h [2]. Checked on x86_64-linux-gnu and aarch64-linux-gnu. [1] https://reviews.llvm.org/D137268 [2] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/wchar.h.html	3 years ago
Adhemerval Zanella	95c9a6e806	Fix special case for C2x strtol binary constant handling (BZ# 30371) 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>	3 years ago
Carlos O'Donell	3643fb0a94	wcsmbs: Reformat Makefile. Reflow Makefile. Sort using updated scripts/sort-makefile-lines.py. Code generation is changed as routines are linked in sorted order as expected. No regressions on x86_64 and i686. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>	3 years ago
Carlos O'Donell	40b68e8cc0	wcsmbs: Reformat Makefile. Reflow Makefile. Sort using scripts/sort-makefile-lines.py. No code generation changes observed in binary artifacts. No regressions on x86_64 and i686.	3 years ago
Joe Simmons-Talbott	0aa5b28a50	wcsmbs: Add wcsdup() tests. (BZ #30266 ) Enable wide character testcases for wcsdup(). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	3 years ago
Florian Weimer	060cadaab6	wcsmbs: Re-flow and sort routines, tests variables in Makefile Eliminate strop-tests because it does not seem to be a simplification. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	3 years ago
Joseph Myers	9e2ff880f3	Declare wcstofN, wcstofNx for C2x WG14 accepted the changes in N3105 to define wcstofN and wcstofNx functions for C2x. Thus enable those for C2x (given also __GLIBC_USE (IEC_60559_TYPES_EXT) and support for the relevant _FloatN / _FloatNx type) rather than only for __USE_GNU. Tested for x86_64.	3 years ago
Joseph Myers	dee2bea048	C2x scanf binary constant handling C2x adds binary integer constants starting with 0b or 0B, and supports those constants for the %i scanf format (in addition to the %b format, which isn't yet implemented for scanf in glibc). Implement that scanf support for glibc. As with the strtol support, 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 input potentially matching subsequent parts of the scanf format string). Thus this patch adds 12 new __isoc23_* functions per long double format (12, 24 or 36 depending on how many long double formats the glibc configuration supports), with appropriate header redirection support (generally very closely following that for the __isoc99_* scanf functions - note that __GLIBC_USE (DEPRECATED_SCANF) takes precedence over __GLIBC_USE (C2X_STRTOL), so the case of GNU extensions to C89 continues to get old-style GNU %a and does not get this new feature). The function names would remain as __isoc23_* even if C2x ends up published in 2024 rather than 2023. When scanf %b support is added, I think it will be appropriate for all versions of scanf to follow C2x rules for inputs to the %b format (given that there are no compatibility concerns for a new format). Tested for x86_64 (full glibc testsuite). The first version was also tested for powerpc (32-bit) and powerpc64le (stdio-common/ and wcsmbs/ tests), and with build-many-glibcs.py.	3 years ago
Joseph Myers	64924422a9	C2x strtol binary constant handling 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.	3 years ago
Joseph Myers	6d7e8eda9b	Update copyright dates with scripts/update-copyrights	3 years ago
Adhemerval Zanella	8d98c7c00f	configure: Use -Wno-ignored-attributes if compiler warns about multiple aliases clang emits an warning when a double alias redirection is used, to warn the the original symbol will be used even when weak definition is overridden. However, this is a common pattern for weak_alias, where multiple alias are set to same symbol. Reviewed-by: Fangrui Song <maskray@google.com>	4 years ago
Florian Weimer	58548b9d68	Use PTR_MANGLE and PTR_DEMANGLE unconditionally in C sources In the future, this will result in a compilation failure if the macros are unexpectedly undefined (due to header inclusion ordering or header inclusion missing altogether). Assembler sources are more difficult to convert. In many cases, they are hand-optimized for the mangling and no-mangling variants, which is why they are not converted. sysdeps/s390/s390-32/__longjmp.c and sysdeps/s390/s390-64/__longjmp.c are special: These are C sources, but most of the implementation is in assembler, so the PTR_DEMANGLE macro has to be undefined in some cases, to match the assembler style. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	3 years ago
Florian Weimer	88f4b6929c	Introduce <pointer_guard.h>, extracted from <sysdep.h> This allows us to define a generic no-op version of PTR_MANGLE and PTR_DEMANGLE. In the future, we can use PTR_MANGLE and PTR_DEMANGLE unconditionally in C sources, avoiding an unintended loss of hardening due to missing include files or unlucky header inclusion ordering. In i386 and x86_64, we can avoid a <tls.h> dependency in the C code by using the computed constant from <tcb-offsets.h>. <sysdep.h> no longer includes these definitions, so there is no cyclic dependency anymore when computing the <tcb-offsets.h> constants. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	3 years ago
Adhemerval Zanella Netto	de477abcaa	Use '%z' instead of '%Z' on printf functions 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>	4 years ago
Raphael Moreira Zinsly	c7509d49c4	Apply asm redirections in wchar.h before first use Similar to `d0fa09a770`, but for wchar.h. Fixes [BZ #27087] by applying all long double related asm redirections before using functions in bits/wchar2.h. Moves the function declarations from wcsmbs/bits/wchar2.h to a new file wcsmbs/bits/wchar2-decl.h that will be included first in wcsmbs/wchar.h. Tested with build-many-glibcs.py. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	4 years ago
H.J. Lu	e03f5ccd6c	wcsmbs: Add missing test-c8rtomb/test-mbrtoc8 dependency Make test-c8rtomb.out and test-mbrtoc8.out depend on $(gen-locales) for xsetlocale (LC_ALL, "de_DE.UTF-8"); xsetlocale (LC_ALL, "zh_HK.BIG5-HKSCS"); Reviewed-by: Sunil K Pandey <skpgkp2@gmail.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>	4 years ago
Tom Honermann	825f84f133	stdlib: Suppress gcc diagnostic that char8_t is a keyword in C++20 in uchar.h. gcc 13 issues the following diagnostic for the uchar.h header when the -Wc++20-compat option is enabled in C++ modes that do not enable char8_t as a builtin type (C++17 and earlier by default; subject to _GNU_SOURCE and the gcc -f[no-]char8_t option). warning: identifier ‘char8_t’ is a keyword in C++20 [-Wc++20-compat] This change modifies the uchar.h header to suppress the diagnostic through the use of '#pragma GCC diagnostic' directives for gcc 10 and later (the -Wc++20-compat option was added in gcc version 10). Unfortunately, a bug in gcc currently prevents those directives from having the intended effect as reported at https://gcc.gnu.org/PR106423. A patch for that issue has been submitted and is available in the email thread archive linked below. https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598736.html	4 years ago
Tom Honermann	f4fe72a4f7	stdlib: Tests for mbrtoc8, c8rtomb, and the char8_t typedef. This change adds tests for the mbrtoc8 and c8rtomb functions adopted for C++20 via WG21 P0482R6 and for C2X via WG14 N2653, and for the char8_t typedef adopted for C2X from WG14 N2653. The tests for mbrtoc8 and c8rtomb specifically exercise conversion to and from Big5-HKSCS because of special cases that arise with that encoding. Big5-HKSCS defines some double byte sequences that convert to more than one Unicode code point. In order to test this, the locale dependencies for running tests under wcsmbs is expanded to include zh_HK.BIG5-HKSCS. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	4 years ago
Tom Honermann	8bcca1db3d	stdlib: Implement mbrtoc8, c8rtomb, and the char8_t typedef. This change provides implementations for the mbrtoc8 and c8rtomb functions adopted for C++20 via WG21 P0482R6 and for C2X via WG14 N2653. It also provides the char8_t typedef from WG14 N2653. The mbrtoc8 and c8rtomb functions are declared in uchar.h in C2X mode or when the _GNU_SOURCE macro or C++20 __cpp_char8_t feature test macro is defined. The char8_t typedef is declared in uchar.h in C2X mode or when the _GNU_SOURCE macro is defined and the C++20 __cpp_char8_t feature test macro is not defined (if __cpp_char8_t is defined, then char8_t is a builtin type). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	4 years ago
Florian Weimer	93ec1cf0fe	locale: Add more cached data to LC_CTYPE This data will be used in number formatting. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	4 years ago
Florian Weimer	7ee41feba6	locale: Remove private union from struct __locale_data This avoids an alias violation later. This commit also fixes an incorrect double-checked locking idiom in _nl_init_era_entries. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	4 years ago
Florian Weimer	bbebe83a28	locale: Remove cleanup function pointer from struct __localedata We can call the cleanup functions directly from _nl_unload_locale if we pass the category to it. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	4 years ago
Siddhesh Poyarekar	9bcd12d223	wcrtomb: Make behavior POSIX compliant The GNU implementation of wcrtomb assumes that there are at least MB_CUR_MAX bytes available in the destination buffer passed to wcrtomb as the first argument. This is not compatible with the POSIX definition, which only requires enough space for the input wide character. This does not break much in practice because when users supply buffers smaller than MB_CUR_MAX (e.g. in ncurses), they compute and dynamically allocate the buffer, which results in enough spare space (thanks to usable_size in malloc and padding in alloca) that no actual buffer overflow occurs. However when the code is built with _FORTIFY_SOURCE, it runs into the hard check against MB_CUR_MAX in __wcrtomb_chk and hence fails. It wasn't evident until now since dynamic allocations would result in wcrtomb not being fortified but since _FORTIFY_SOURCE=3, that limitation is gone, resulting in such code failing. To fix this problem, introduce an internal buffer that is MB_LEN_MAX long and use that to perform the conversion and then copy the resultant bytes into the destination buffer. Also move the fortification check into the main implementation, which checks the result after conversion and aborts if the resultant byte count is greater than the destination buffer size. One complication is that applications that assume the MB_CUR_MAX limitation to be gone may not be able to run safely on older glibcs if they use static destination buffers smaller than MB_CUR_MAX; dynamic allocations will always have enough spare space that no actual overruns will occur. One alternative to fixing this is to bump symbol version to prevent them from running on older glibcs but that seems too strict a constraint. Instead, since these users will only have made this decision on reading the manual, I have put a note in the manual warning them about the pitfalls of having static buffers smaller than MB_CUR_MAX and running them on older glibc. Benchmarking: The wcrtomb microbenchmark shows significant increases in maximum execution time for all locales, ranging from 10x for ar_SA.UTF-8 to 1.5x-2x for nearly everything else. The mean execution time however saw practically no impact, with some results even being quicker, indicating that cache locality has a much bigger role in the overhead. Given that the additional copy uses a temporary buffer inside wcrtomb, it's likely that a hot path will end up putting that buffer (which is responsible for the additional overhead) in a similar place on stack, giving the necessary cache locality to negate the overhead. However in situations where wcrtomb ends up getting called at wildly different spots on the call stack (or is on different call stacks, e.g. with threads or different execution contexts) and is still a hotspot, the performance lag will be visible. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>	4 years ago
Siddhesh Poyarekar	fcfc908681	debug: Synchronize feature guards in fortified functions [BZ #28746 ] Some functions (e.g. stpcpy, pread64, etc.) had moved to POSIX in the main headers as they got incorporated into the standard, but their fortified variants remained under __USE_GNU. As a result, these functions did not get fortified when _GNU_SOURCE was not defined. Add test wrappers that check all functions tested in tst-chk0 at all levels with _GNU_SOURCE undefined and then use the failures to (1) exclude checks for _GNU_SOURCE functions in these tests and (2) Fix feature macro guards in the fortified function headers so that they're the same as the ones in the main headers. This fixes BZ #28746. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	4 years ago
Paul Eggert	581c785bf3	Update copyright dates with scripts/update-copyrights I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 7061 files FOO. I then removed trailing white space from math/tgmath.h, support/tst-support-open-dev-null-range.c, and sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following obscure pre-commit check failure diagnostics from Savannah. I don't know why I run into these diagnostics whereas others evidently do not. remote: * 912-#endif remote: * 913: remote: * 914- remote: * error: lines with trailing whitespace found ... remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines	4 years ago
Joseph Myers	309548bec3	Support C2X printf %b, %B C2X adds a printf %b format (see <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2630.pdf>, accepted for C2X), for outputting integers in binary. It also has recommended practice for a corresponding %B format (like %b, but %#B starts the output with 0B instead of 0b). Add support for these formats to glibc. One existing test uses %b as an example of an unknown format, to test how glibc printf handles unknown formats; change that to %v. Use of %b and %B as user-registered format specifiers continues to work (and we already have a test that covers that, tst-printfsz.c). Note that C2X also has scanf %b support, plus support for binary constants starting 0b in strtol (base 0 and 2) and scanf %i (strtol base 0 and scanf %i coming from a previous paper that added binary integer literals). I intend to implement those features in a separate patch or patches; as discussed in the thread starting at <https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>, they will be more complicated because they involve adding extra public symbols to ensure compatibility with existing code that might not expect 0b constants to be handled by strtol base 0 and 2 and scanf %i, whereas simply adding a new format specifier poses no such compatibility concerns. Note that the actual conversion from integer to string uses existing code in _itoa.c. That code has special cases for bases 8, 10 and 16, probably so that the compiler can optimize division by an integer constant in the code for those bases. If desired such special cases could easily be added for base 2 as well, but that would be an optimization, not actually needed for these printf formats to work. Tested for x86_64 and x86. Also tested with build-many-glibcs.py for aarch64-linux-gnu with GCC mainline to make sure that the test does indeed build with GCC 12 (where format checking warnings are enabled for most of the test).	4 years ago
Siddhesh Poyarekar	a643f60c53	Make sure that the fortified function conditionals are constant In _FORTIFY_SOURCE=3, the size expression may be non-constant, resulting in branches in the inline functions remaining intact and causing a tiny overhead. Clang (and in future, gcc) make sure that the -1 case is always safe, i.e. any comparison of the generated expression with (size_t)-1 is always false so that bit is taken care of. The rest is avoidable since we want the _chk variant whenever we have a size expression and it's not -1. Rework the conditionals in a uniform way to clearly indicate two conditions at compile time: - Either the size is unknown (-1) or we know at compile time that the operation length is less than the object size. We can call the original function in this case. It could be that either the length, object size or both are non-constant, but the compiler, through range analysis, is able to fold the comparison to a constant. - The size and length are known and the compiler can see at compile time that operation length > object size. This is valid grounds for a warning at compile time, followed by emitting the _chk variant. For everything else, emit the _chk variant. This simplifies most of the fortified function implementations and at the same time, ensures that only one call from _chk or the regular function is emitted. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>	5 years ago
Siddhesh Poyarekar	30891f35fa	Remove "Contributed by" lines We stopped adding "Contributed by" or similar lines in sources in 2012 in favour of git logs and keeping the Contributors section of the glibc manual up to date. Removing these lines makes the license header a bit more consistent across files and also removes the possibility of error in attribution when license blocks or files are copied across since the contributed-by lines don't actually reflect reality in those cases. Move all "Contributed by" and similar lines (Written by, Test by, etc.) into a new file CONTRIBUTED-BY to retain record of these contributions. These contributors are also mentioned in manual/contrib.texi, so we just maintain this additional record as a courtesy to the earlier developers. The following scripts were used to filter a list of files to edit in place and to clean up the CONTRIBUTED-BY file respectively. These were not added to the glibc sources because they're not expected to be of any use in future given that this is a one time task: https://gist.github.com/siddhesh/b5ecac94eabfd72ed2916d6d8157e7dc https://gist.github.com/siddhesh/15ea1f5e435ace9774f485030695ee02 Reviewed-by: Carlos O'Donell <carlos@redhat.com>	5 years ago
Martin Sebor	c1760eaf3b	Enable support for GCC 11 -Wmismatched-dealloc. To help detect common kinds of memory (and other resource) management bugs, GCC 11 adds support for the detection of mismatched calls to allocation and deallocation functions. At each call site to a known deallocation function GCC checks the set of allocation functions the former can be paired with and, if the two don't match, issues a -Wmismatched-dealloc warning (something similar happens in C++ for mismatched calls to new and delete). GCC also uses the same mechanism to detect attempts to deallocate objects not allocated by any allocation function (or pointers past the first byte into allocated objects) by -Wfree-nonheap-object. This support is enabled for built-in functions like malloc and free. To extend it beyond those, GCC extends attribute malloc to designate a deallocation function to which pointers returned from the allocation function may be passed to deallocate the allocated objects. Another, optional argument designates the positional argument to which the pointer must be passed. This change is the first step in enabling this extended support for Glibc.	5 years ago
Paul Eggert	2b778ceb40	Update copyright dates with scripts/update-copyrights I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 6694 files FOO. I then removed trailing white space from benchtests/bench-pthread-locks.c and iconvdata/tst-iconv-big5-hkscs-to-2ucs4.c, to work around this diagnostic from Savannah: remote: * pre-commit check failed ... remote: * error: lines with trailing whitespace found remote: error: hook declined to update refs/heads/master	5 years ago
Siddhesh Poyarekar	f9de8bfe1a	nonstring: Enable __FORTIFY_LEVEL=3 Use __builtin_dynamic_object_size in the remaining functions that don't have compiler builtins as is the case for string functions.	5 years ago
Joseph Myers	224b419d1e	Make strtoimax, strtoumax, wcstoimax, wcstoumax into aliases The functions strtoimax, strtoumax, wcstoimax, wcstoumax currently have three implementations each (wordsize-32, wordsize-64 and dummy implementation in stdlib/ using #error), defining the functions as thin wrappers round corresponding *_internal functions. Simplify the code by changing them into aliases of functions such as strtol and wcstoull. This is more consistent with how e.g. imaxdiv is handled. Tested for x86_64 and x86.	5 years ago
Carlos O'Donell	61af4bbb2a	mbstowcs: Document, test, and fix null pointer dst semantics (Bug 25219) The function mbstowcs, by an XSI extension to POSIX, accepts a null pointer for the destination wchar_t array. This API behaviour allows you to use the function to compute the length of the required wchar_t array i.e. does the conversion without storing it and returns the number of wide characters required. We remove the __write_only__ markup for the first argument because it is not true since the destination may be a null pointer, and so the length argument may not apply. We remove the markup otherwise the new test case cannot be compiled with -Werror=nonnull. We add a new test case for mbstowcs which exercises the destination is a null pointer behaviour which we have now explicitly documented. The mbsrtowcs and mbsnrtowcs behave similarly, and mbsrtowcs is documented as doing this in C11, even if the standard doesn't come out and call out this specific use case. We add one note to each of mbsrtowcs and mbsnrtowcs to call out that they support a null pointer for the destination. The wcsrtombs function behaves similarly but in the other way around and allows you to use a null destination pointer to compute how many bytes you would need to convert the wide character input. We document this particular case also, but leave wcsnrtombs as a references to wcsrtombs, so the reader must still read the details of the semantics for wcsrtombs.	6 years ago
Paul E. Murphy	e2239af353	Rename __LONG_DOUBLE_USES_FLOAT128 to __LDOUBLE_REDIRECTS_TO_FLOAT128_ABI Improve the commentary to aid future developers who will stumble upon this novel, yet not always perfect, mechanism to support alternative formats for long double. Likewise, rename __LONG_DOUBLE_USES_FLOAT128 to __LDOUBLE_REDIRECTS_TO_FLOAT128_ABI now that development work has settled down. The command used was git grep -l __LONG_DOUBLE_USES_FLOAT128 ':!./ChangeLog*' \| \ xargs sed -i 's/__LONG_DOUBLE_USES_FLOAT128/__LDOUBLE_REDIRECTS_TO_FLOAT128_ABI/g' Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>	6 years ago
Gabriel F. T. Gomes	e4a3999213	Prepare redirections for IEEE long double on powerpc64le All functions that have a format string, which can consume a long double argument, must have one version for each long double format supported on a platform. On powerpc64le, these functions currently have two versions (i.e.: long double with the same format as double, and long double with IBM Extended Precision format). Support for a third long double format option (i.e. long double with IEEE long double format) is being prepared and all the aforementioned functions now have a third version (not yet exported on the master branch, but the code is in). For these functions to get selected (during build time), references to them in user programs (or dependent libraries) must get redirected to the aforementioned new versions of the functions. This patch installs the header magic required to perform such redirections. Notice, however, that since the redirections only happen when __LONG_DOUBLE_USES_FLOAT128 is set to 1, and no platform (including powerpc64le) currently does it, no redirections actually happen. Redirections and the exporting of the new functions will happen at the same time (when powerpc64le adds ldbl-128ibm-compat to their Implies. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> Reviewed-by: Paul E. Murphy <murphyp@linux.vnet.ibm.com>	6 years ago
Joseph Myers	d614a75396	Update copyright dates with scripts/update-copyrights.	6 years ago
Gabriel F. T. Gomes	93486ba583	Use DEPRECATED_SCANF macro for remaining C99-compliant scanf functions When the commit commit `03992356e6` Author: Zack Weinberg <zackw@panix.com> Date: Sat Feb 10 11:58:35 2018 -0500 Use C99-compliant scanf under _GNU_SOURCE with modern compilers. added the DEPRECATED_SCANF macro to select when redirections of *scanf functions to their ISO C99 compliant versions should happen, it accidentally missed doing it for vfwscanf, vwscanf, and vswscanf. Tested for powerpc64le and with build-many-glibcs (i686-linux-gnu and nios2-linux-gnu are failing with current master, and with this patch, but I didn't see a regression). Change-Id: I706b344a3fb50be017cdab9251d9da18a3ba8c60	6 years ago

1 2 3 4 5 ...

435 Commits (fa3eb7d5e7d32ca1ad48b48a7eb6d15b8382c3a7)