about summary refs log tree commit diff
path: root/stdio-common
Commit message (Collapse)AuthorAgeFilesLines
* libio: Remove the usage of __libc_IO_vtablesAdhemerval Zanella Netto2023-03-272-52/+4
| | | | | | | | | | | | | | Instead of using a special ELF section along with a linker script directive to put the IO vtables within the RELRO section, the libio vtables are all moved to an array marked as data.relro (so linker will place in the RELRO segment without the need of extra directives). To avoid static linking namespace issues and including all vtable referenced objects, all required function pointers are set to weak alias. Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* libio: Do not autogenerate stdio_lim.hAdhemerval Zanella Netto2023-03-271-39/+0
| | | | | | | | | | | | | Instead define the required fields in system dependend files. The only system dependent definition is FILENAME_MAX, which should match POSIX PATH_MAX, and it is obtained from either kernel UAPI or mach headers. Currently set pre-defined value from current kernels. It avoids a circular dependendy when including stdio.h in gen-as-const-headers files. Checked on x86_64-linux-gnu and i686-linux-gnu Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Move libc_freeres_ptrs and libc_subfreeres to hidden/weak functionsAdhemerval Zanella Netto2023-03-273-5/+10
| | | | | | | | | | | | | | | | | | | | 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>
* stdio-common: tests: don't double-define _FORTIFY_SOURCESam James2023-03-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Exactly the same as 35bcb08eaa953c9b8bef6ab2486dc4361e1f26c0. 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 tst-bz11319-fortify2 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 ``` 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.) As Siddhesh noted previously, we could implement some fallback logic to determine the maximal F_S value supported by the toolchain, which is a bit easier now that autoconf-archive has been updated for F_S=3 (https://github.com/autoconf-archive/autoconf-archive/pull/269), but let's revisit this if it continues to crop up. Signed-off-by: Sam James <sam@gentoo.org> Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Update printf %b/%B C2x supportJoseph Myers2023-03-141-0/+53
| | | | | | | | | | | | | | | | 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.
* C2x scanf binary constant handlingJoseph Myers2023-03-0214-0/+530
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* stdio: Do not ignore posix_spawn error on popen (BZ #29016)Adhemerval Zanella2023-02-142-0/+41
| | | | | | To correctly return error in case of default shell is not present. Checked on x86_64-linux-gnu.
* Account for grouping in printf width (bug 30068)Carlos O'Donell2023-02-063-5/+73
| | | | | | | | | This is a partial fix for mishandling of grouping when formatting integers. It properly computes the width in the presence of grouping characters when the width is larger than the number of significant digits. The precision related issue is documented in bug 23432. Co-authored-by: Andreas Schwab <schwab@suse.de>
* libio: Update number of written bytes in dprintf implementationFlorian Weimer2023-01-312-0/+46
| | | | | | | | | | | | The __printf_buffer_flush_dprintf function needs to record that the buffer has been written before reusing it. Without this accounting, dprintf always returns zero. Fixes commit 8ece45e4f586abd212d1c02d74d38ef681a45600 ("libio: Convert __vdprintf_internal to buffers"). Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Account for octal marker in %#o formatAndreas Schwab2023-01-303-0/+56
|
* Update copyright dates with scripts/update-copyrightsJoseph Myers2023-01-06162-162/+162
|
* libio: Convert __vswprintf_internal to buffers (bug 27857)Florian Weimer2022-12-191-0/+6
| | | | | | | Always null-terminate the buffer and set E2BIG if the buffer is too small. This fixes bug 27857. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* libio: Convert __obstack_vprintf_internal to buffers (bug 27124)Florian Weimer2022-12-191-0/+4
| | | | | | This fixes bug 27124 because the problematic built-in vtable is gone. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* libio: Convert __vdprintf_internal to buffersFlorian Weimer2022-12-191-0/+4
| | | | | | | | | The internal buffer size is set to 2048 bytes. This is less than the original BUFSIZ value used by buffered_vfprintf before the conversion, but it hopefully covers all cases where write boundaries matter. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* libio: Convert __vasprintf_internal to buffersFlorian Weimer2022-12-191-0/+4
| | | | | | | | | | The buffer resizing algorithm is slightly different. The initial buffer is on the stack, and small buffers are directly allocated on the heap using the exact required size. The overhead of the additional copy is compensated by the lowered setup cost for buffers compared to libio streams. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* libio: Convert __vsprintf_internal to buffersFlorian Weimer2022-12-191-0/+4
| | | | Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio-common: Add lock optimization to vfprintf and vfwprintfFlorian Weimer2022-12-191-0/+8
| | | | | | | After the rewrite and the implicit unbuffered streams handling, this is very straightforward to add. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio-common: Convert vfprintf and related functions to buffersFlorian Weimer2022-12-195-1135/+720
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vfprintf is entangled with vfwprintf (of course), __printf_fp, __printf_fphex, __vstrfmon_l_internal, and the strfrom family of functions. The latter use the internal snprintf functionality, so vsnprintf is converted as well. The simples conversion is __printf_fphex, followed by __vstrfmon_l_internal and __printf_fp, and finally __vfprintf_internal and __vfwprintf_internal. __vsnprintf_internal and strfrom* are mostly consuming the new interfaces, so they are comparatively simple. __printf_fp is a public symbol, so the FILE *-based interface had to preserved. The __printf_fp rewrite does not change the actual binary-to-decimal conversion algorithm, and digits are still not emitted directly to the target buffer. However, the staging buffer now uses bytes instead of wide characters, and one buffer copy is eliminated. The changes are at least performance-neutral in my testing. Floating point printing and snprintf improved measurably, so that this Lua script for i=1,5000000 do print(i, i * math.pi) end runs about 5% faster for me. To preserve fprintf performance for a simple "%d" format, this commit has some logic changes under LABEL (unsigned_number) to avoid additional function calls. There are certainly some very easy performance improvements here: binary, octal and hexadecimal formatting can easily avoid the temporary work buffer (the number of digits can be computed ahead-of-time using one of the __builtin_clz* built-ins). Decimal formatting can use a specialized version of _itoa_word for base 10. The existing (inconsistent) width handling between strfmon and printf is preserved here. __print_fp_buffer_1 would have to use __translated_number_width to achieve ISO conformance for printf. Test expectations in libio/tst-vtables-common.c are adjusted because the internal staging buffer merges all virtual function calls into one. In general, stack buffer usage is greatly reduced, particularly for unbuffered input streams. __printf_fp can still use a large buffer in binary128 mode for %g, though. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio-common: Add __translated_number_widthFlorian Weimer2022-12-192-0/+43
| | | | | | | This function will be used to compute the width of a number after i18n digit translation. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio-common: Add __printf_function_invokeFlorian Weimer2022-12-194-0/+104
| | | | | | | | | And __wprintf_function_invoke. These functions will be used to to call registered printf specifier callbacks on printf buffers after vfprintf and vfwprintf have been converted to buffers. The new implementation avoids alloca/variable length arrays. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio-common: Introduce buffers for implementing printfFlorian Weimer2022-12-1927-0/+1241
| | | | | | | | | | | | | | | | | | | | | | | | | | These buffers will eventually be used instead of FILE * objects to implement printf functions. The multibyte buffer is struct __printf_buffer, the wide buffer is struct __wprintf_buffer. To enable writing type-generic code, the header files printf_buffer-char.h and printf_buffer-wchar_t.h define the Xprintf macro differently, enabling Xprintf (buffer) to stand for __printf_buffer and __wprintf_buffer as appropriate. For common cases, macros like Xprintf_buffer are provided as a more syntactically convenient shortcut. Buffer-specific flush callbacks are implemented with a switch statement instead of a function pointer, to avoid hardening issues similar to those of libio vtables. struct __printf_buffer_as_file is needed to support custom printf specifiers because the public interface for that requires passing a FILE *, which is why there is a trapdoor back from these buffers to FILE * streams. Since the immediate user of these interfaces knows when processing has finished, there is no flush callback for the end of processing, only a flush callback for the intermediate buffer flush. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* locale: Implement struct grouping_iteratorFlorian Weimer2022-12-194-1/+461
| | | | | | | The iterator allows grouping while scanning forward through the digits. This enables emitting digits as they are processed. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio-common: Add missing dependencies (bug 29780)Andreas Schwab2022-11-211-2/+4
| | | | | Handle all object suffixes for dependencies of errlist-data and siglist objects.
* configure: Use -Wno-ignored-attributes if compiler warns about multiple aliasesAdhemerval Zanella2022-11-011-0/+2
| | | | | | | | | 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>
* Fix missing NUL terminator in stdio-common/scanf13 testSzabolcs Nagy2022-10-281-0/+1
| | | | | | | | sscanf is only defined on nul terminated string input, but '\0' was missing in this test which caused _IO_str_init_static_internal to read OOB on the stack when computing the bounds of the string. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* tst-sprintf-errno: Update Hurd message lengthSamuel Thibault2022-09-171-1/+1
| | | | | | | 03ad444e8e08 ("mach: Fix incoherency between perror and strerror") fixesd the output of error messages, but tst-sprintf-errno.c was still checking the old (erroneous) format length. This updates the expected output length according to the 03ad444e8e08 fix.
* tst-sprintf-errno: Update Hurd message outputSamuel Thibault2022-09-111-1/+1
| | | | | | | 03ad444e8e08 ("mach: Fix incoherency between perror and strerror") fixesd the output of error messages, but tst-sprintf-errno.c was still checking the old (erroneous) format. This updates the expected output according to the 03ad444e8e08 fix.
* errlist: add missing entry for EDEADLOCK (bug 29545)Andreas Schwab2022-09-081-0/+8
| | | | | | | Some architectures (mips, powerpc and sparc) define separate values for EDEADLOCK and EDEADLK. Readd the errlist entry for EDEADLOCK for those configurations. Also use the dependency files from generating the auxiliary errlist and siglist files.
* Add test for bug 29530Andreas Schwab2022-08-292-0/+41
| | | | | | | This tests for a bug that was introduced in commit edc1686af0 ("vfprintf: Reuse work_buffer in group_number") and fixed as a side effect of commit 6caddd34bd ("Remove most vfprintf width/precision-dependent allocations (bug 14231, bug 26211).").
* libio: Avoid RMW of flags2 outside lock (BZ #27842)Wilco Dijkstra2022-06-101-1/+0
| | | | | | | | Remove an unconditional RMW on flags2 in flockfile - we don't need to change _IO_FLAGS2_NEED_LOCK since it isn't used in flockfile or funlockfile. This fixes BZ #27842. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio-common: Simplify printf_unknown interface in vfprintf-internal.cFlorian Weimer2022-05-241-18/+3
| | | | | | | The called function does not use the args array, so there is no need to produce it. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio-common: Move union printf_arg int <printf.h>Florian Weimer2022-05-241-23/+0
| | | | | | | The type does not depend on wide vs narrow preprocessor macros, so it does not need to be customized in stdio-common/printf-parse.h. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio-common: Add printf specifier registry to <printf.h>Florian Weimer2022-05-244-14/+1
| | | | | | Add __printf_arginfo_table, __printf_function_table, __printf_va_arg_table, __register_printf_specifier to include/printf.h.
* stdio-common: Add tst-memstream-string for open_memstream overflowFlorian Weimer2022-05-232-0/+80
| | | | | | | | | | This code path is exercised indirectly by some of the DNS stub resolver tests, via their own use of xopen_memstream for constructing strings describing result data. The relative lack of test suite coverage became apparent when these tests starting failing after a printf changes uncovered bug 28949. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* __printf_fphex always uses LC_NUMERICFlorian Weimer2022-05-231-19/+11
| | | | | | | There is no hexadecimal currency printing. strfmon uses __printf_fp_l exclusively. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* vfprintf: Consolidate some multibyte/wide character processingFlorian Weimer2022-05-231-87/+43
| | | | | | | form_character and form_string processing a sufficiently similar that the logic can be shared. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* vfprintf: Move argument processing into vfprintf-process-arg.cFlorian Weimer2022-05-232-499/+517
| | | | | | | This simplies formatting and helps with debugging. It also allows the use of localized COMPILE_WPRINTF preprocessor conditionals. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio-common: Add tst-vfprintf-width-i18n to cover numeric field widthFlorian Weimer2022-05-232-0/+98
| | | | | | Related to bug 28943 and bug 28944. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio: Remove the usage of $(fno-unit-at-a-time) for siglist.cAdhemerval Zanella2022-05-133-5/+20
| | | | | | | | | | | | | | | | | | The siglist.c is built with -fno-toplevel-reorder to avoid compiler to reorder the compat assembly directives due an assembler issue [1] (fixed on 2.39). This patch removes the compiler flags by split the compat symbol generation in two phases. First the __sys_siglist and __sys_sigabbrev without any compat symbol directive is preprocessed to generate an assembly source code. This generate assembly is then used as input on a platform agnostic siglist.S which then creates the compat definitions. This prevents compiler to move any compat directive prior the _sys_errlist definition itself. Checked on a make check run-built-tests=no on all affected ABIs. Reviewed-by: Fangrui Song <maskray@google.com>
* stdio: Remove the usage of $(fno-unit-at-a-time) for errlist.cAdhemerval Zanella2022-05-137-18/+89
| | | | | | | | | | | | | | | | | | The errlist.c is built with -fno-toplevel-reorder to avoid compiler to reorder the compat assembly directives due an assembler issue [1] (fixed on 2.39). This patch removes the compiler flags by split the compat symbol generation in two phases. First the _sys_errlist_internal internal without any compat symbol directive is preprocessed to generate an assembly source code. This generate assembly is then used as input on a platform agnostic errlist-data.S which then creates the compat definitions. This prevents compiler to move any compat directive prior the _sys_errlist_internal definition itself. Checked on a make check run-built-tests=no on all affected ABIs. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29012
* stdio: Split __get_errname definition from errlist.cAdhemerval Zanella2022-04-153-36/+64
| | | | | | | | | | | | | | | | | The loader does not need to pull all __get_errlist definitions and its size is decreased: Before: $ size elf/ld.so text data bss dec hex filename 197774 11024 456 209254 33166 elf/ld.so After: $ size elf/ld.so text data bss dec hex filename 191510 9936 456 201902 314ae elf/ld.so Checked on x86_64-linux-gnu.
* stdio-common: Add wide stream coverage to tst-vfprintf-user-typeFlorian Weimer2022-03-181-27/+93
| | | | | | And use TEST_COMPARE_STRING for the narrow tests. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdio-common: Generate ja_JP.EUC-JP localeFlorian Weimer2022-03-171-0/+1
| | | | It is needed by tst-swprintf.
* stdio-common: Re-flow and sort Makefile variablesFlorian Weimer2022-03-171-66/+217
|
* Update copyright dates with scripts/update-copyrightsPaul Eggert2022-01-01122-122/+122
| | | | | | | | | | | | | | | | | | | | | | | 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
* stdio-common: Fix %m sprintf test output for GNU/HurdSamuel Thibault2021-12-271-0/+10
| | | | | GNU/Hurd has slightly different error messages for undefined numbers, due to the notion of error subsystems.
* stdio: Implement %#m for vfprintf and related functionsFlorian Weimer2021-12-233-6/+116
| | | | | | | | | %#m prints errno as an error constant if one is available, or a decimal number as a fallback. This intends to address the gap that strerrorname_np does not work well with printf for unknown error codes due to its NULL return values in those cases. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Support C2X printf %b, %BJoseph Myers2021-11-107-21/+193
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Fix memmove call in vfprintf-internal.c:group_numberJoseph Myers2021-11-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A recent GCC mainline change introduces errors of the form: vfprintf-internal.c: In function 'group_number': vfprintf-internal.c:2093:15: error: 'memmove' specified bound between 9223372036854775808 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] 2093 | memmove (w, s, (front_ptr -s) * sizeof (CHAR_T)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is a genuine bug in the glibc code: s > front_ptr is always true at this point in the code, and the intent is clearly for the subtraction to be the other way round. The other arguments to the memmove call here also appear to be wrong; w and s point just *after* the destination and source for copying the rest of the number, so the size needs to be subtracted to get appropriate pointers for the copying. Adjust the memmove call to conform to the apparent intent of the code, so fixing the -Wstringop-overflow error. Now, if the original code were ever executed, a buffer overrun would result. However, I believe this code (introduced in commit edc1686af0c0fc2eb535f1d38cdf63c1a5a03675, "vfprintf: Reuse work_buffer in group_number", so in glibc 2.26) is unreachable in prior glibc releases (so there is no need for a bug in Bugzilla, no need to consider any backports unless someone wants to build older glibc releases with GCC 12 and no possibility of this buffer overrun resulting in a security issue). work_buffer is 1000 bytes / 250 wide characters. This case is only reachable if an initial part of the number, plus a grouped copy of the rest of the number, fail to fit in that space; that is, if the grouped number fails to fit in the space. In the wide character case, grouping is always one wide character, so even with a locale (of which there aren't any in glibc) grouping every digit, a number would need to occupy at least 125 wide characters to overflow, and a 64-bit integer occupies at most 23 characters in octal including a leading 0. In the narrow character case, the multibyte encoding of the grouping separator would need to be at least 42 bytes to overflow, again supposing grouping every digit, but MB_LEN_MAX is 16. So even if we admit the case of artificially constructed locales not shipped with glibc, given that such a locale would need to use one of the character sets supported by glibc, this code cannot be reached at present. (And POSIX only actually specifies the ' flag for grouping for decimal output, though glibc acts on it for other bases as well.) With binary output (if you consider use of grouping there to be valid), you'd need a 15-byte multibyte character for overflow; I don't know if any supported character set has such a character (if, again, we admit constructed locales using grouping every digit and a grouping separator chosen to have a multibyte encoding as long as possible, as well as accepting use of grouping with binary), but given that we have this code at all (clearly it's not *correct*, or in accordance with the principle of avoiding arbitrary limits, to skip grouping on running out of internal space like that), I don't think it should need any further changes for binary printf support to go in. On the other hand, support for large sizes of _BitInt in printf (see the N2858 proposal) *would* require something to be done about such arbitrary limits (presumably using dynamic allocation in printf again, for sufficiently large _BitInt arguments only - currently only floating-point uses dynamic allocation, and, as previously discussed, that could actually be replaced by bounded allocation given smarter code). Tested with build-many-glibcs.py for aarch64-linux-gnu (GCC mainline). Also tested natively for x86_64.
* Fix stdio-common tests for GCC 12 -WaddressJoseph Myers2021-10-043-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My glibc bot shows failures building the testsuite with GCC mainline across all architectures: tst-vfprintf-width-prec.c: In function 'do_test': tst-vfprintf-width-prec.c:90:16: error: the comparison will always evaluate as 'false' for the address of 'result' will never be NULL [-Werror=address] 90 | if (result == NULL) | ^~ tst-vfprintf-width-prec.c:89:13: note: 'result' declared here 89 | wchar_t result[100]; | ^~~~~~ This is clearly a correct warning; the comparison against NULL is clearly a cut-and-paste mistake from an earlier case in the test that does use calloc. Thus, remove the unnecessary check for NULL shown up by the warning. Similarly, two other tests have bogus comparisons against NULL; remove those as well: scanf14a.c:95:13: error: the comparison will always evaluate as 'false' for the address of 'fname' will never be NULL [-Werror=address] 95 | if (fname == NULL) | ^~ scanf14a.c:93:8: note: 'fname' declared here 93 | char fname[strlen (tmpdir) + sizeof "/tst-scanf14.XXXXXX"]; | ^~~~~ scanf16a.c:125:13: error: the comparison will always evaluate as 'false' for the address of 'fname' will never be NULL [-Werror=address] 125 | if (fname == NULL) | ^~ scanf16a.c:123:8: note: 'fname' declared here 123 | char fname[strlen (tmpdir) + sizeof "/tst-scanf16.XXXXXX"]; | ^~~~~ Tested with build-many-glibcs.py (GCC mainline) for aarch64-linux-gnu.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-07 11:35:59 +0000