about summary refs log tree commit diff
path: root/stdio-common
Commit message (Collapse)AuthorAgeFilesLines
* Fix freopen handling of ,ccs= (bug 23675)Joseph Myers2024-09-051-5/+0
| | | | | | | | | | | | | As reported in bug 23675 and shown up in the recently added tests of different cases of freopen (relevant part of the test currently conditioned under #if 0 to avoid a failure resulting from this bug), freopen wrongly forces the stream to unoriented even when a mode with ,ccs= is specified, though such a mode is supposed to result in a wide-oriented stream. Move the clearing of _mode to before the actual reopening occurs, so that the main fopen implementation can leave a wide-oriented stream in the ,ccs= case. Tested for x86_64.
* Fix memory leak on freopen error return (bug 32140)Joseph Myers2024-09-052-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As reported in bug 32140, freopen leaks the FILE object when it returns NULL: there is no valid use of the FILE * pointer (including passing to freopen again or to fclose) after such an error return, so the underlying object should be freed. Add code to free it. Note 1: while I think it's clear from the relevant standards that the object should be freed and the FILE * can't be used after the call in this case (the stream is closed, which ends the lifetime of the FILE), it's entirely possible that some existing code does in fact try to use the existing FILE * in some way and could be broken by this change. (Though the most common case for freopen may be stdin / stdout / stderr, which _IO_deallocate_file explicitly checks for and does not deallocate.) Note 2: the deallocation is only done in the _IO_IS_FILEBUF case. Other kinds of streams bypass all the freopen logic handling closing the file, meaning a call to _IO_deallocate_file would neither be safe (the FILE might still be linked into the list of all open FILEs) nor sufficient (other internal memory allocations associated with the file would not have been freed). I think the validity of freopen for any other kind of stream will need clarifying with the Austin Group, but if it is valid in any such case (where "valid" means "not undefined behavior so required to close the stream" rather than "required to successfully associate the stream with the new file in cases where fopen would work"), more significant changes would be needed to ensure the stream gets fully closed. Tested for x86_64.
* Clear flags2 flags set from mode in freopen (bug 32134)Joseph Myers2024-09-051-2/+0
| | | | | | | | | | | | | As reported in bug 32134, freopen does not clear the flags set in fp->_flags2 by the "e", "m" or "c" mode characters. Clear these so that they can be set or not as appropriate from the mode string passed to freopen. The relevant test for "e" in tst-freopen2-main.c is enabled accordingly; "c" is expected to be covered in a separately written test (and while tst-freopen2-main.c does include transitions to and from "m", that's not really a semantic flag intended to result in behaving in an observably different way). Tested for x86_64.
* fgets: more testsDJ Delorie2024-09-042-0/+254
| | | | | | | | | | | | | Add more tests for unusual situations fgets() might see: * zero size file * zero sized buffer * NULL buffer * NUL data * writable stream * closed stream Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Add more thorough tests of freopenJoseph Myers2024-09-047-0/+642
| | | | | | | | | | | | | | | | | | | | | freopen is rather minimally tested in libio/tst-freopen and libio/test-freopen. Add some more thorough tests, covering different cases for change of mode in particular. The tests are run for both freopen and freopen64 (given that those functions have two separate copies of much of the code, so any bug fix directly in the freopen code would probably need applying in both places). Note that there are two parts of the tests disabled because of bugs discovered through running the tests, with bug numbers given in comments. I expect to address those separately. The tests also don't cover changes to cancellation ("c" in mode); I think that will better be handled through a separate test. Also to handle separately: testing on stdin / stdout / stderr; documenting lack of support for streams opened with popen / fmemopen / open_memstream / fopencookie; maybe also a chroot test without /proc; maybe also more thorough tests for large file handling on 32-bit systems (freopen64). Tested for x86_64.
* Add more tests of getlineJoseph Myers2024-08-213-0/+543
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is very little test coverage for getline (only a minimal stdio-common/tstgetln.c which doesn't verify anything about the results of the getline calls). Add some more thorough tests (generally using fopencookie for convenience in testing various cases for what the input and possible errors / EOF in the file read might look like). Note the following regarding testing of error cases: * Nothing is said in the specifications about what if anything might be written into the buffer, and whether it might be reallocated, in error cases. The expectation of the tests (required to avoid memory leaks on error) is that at least on error cases, the invariant that lineptr points to at least n bytes is maintained. * The optional EOVERFLOW error case specified in POSIX, "The number of bytes to be written into the buffer, including the delimiter character (if encountered), would exceed {SSIZE_MAX}.", doesn't seem practically testable, as any case reading so many characters (half the address space) would also be liable to run into allocation failure along (ENOMEM) the way. * If a read error occurs part way through reading an input line, it seems unclear whether a partial line should be returned by getline (avoid input getting lost), which is what glibc does at least in the fopencookie case used in this test, or whether getline should return -1 (error) (so avoiding the program misbehaving by processing a truncated line as if it were complete). (There was a short, inconclusive discussion about this on the Austin Group list on 9-10 November 2014.) * The POSIX specification of getline inherits errors from fgetc. I didn't try to cover fgetc errors systematically, just one example of such an error. Tested for x86_64 and x86.
* support: Use macros for *stat wrappersFlorian Weimer2024-08-161-1/+1
| | | | | | | | | | | | 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>
* ungetc: Fix backup buffer leak on program exit [BZ #27821]Siddhesh Poyarekar2024-08-152-0/+39
| | | | | | | | | | | | | | | | | | | | | If a file descriptor is left unclosed and is cleaned up by _IO_cleanup on exit, its backup buffer remains unfreed, registering as a leak in valgrind. This is not strictly an issue since (1) the program should ideally be closing the stream once it's not in use and (2) the program is about to exit anyway, so keeping the backup buffer around a wee bit longer isn't a real problem. Free it anyway to keep valgrind happy when the streams in question are the standard ones, i.e. stdout, stdin or stderr. Also, the _IO_have_backup macro checks for _IO_save_base, which is a roundabout way to check for a backup buffer instead of directly looking for _IO_backup_base. The roundabout check breaks when the main get area has not been used and user pushes a char into the backup buffer with ungetc. Fix this to use the _IO_backup_base directly. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* ungetc: Fix uninitialized read when putting into unused streams [BZ #27821]Siddhesh Poyarekar2024-08-151-0/+2
| | | | | | | | | | | | | | | | | | | | When ungetc is called on an unused stream, the backup buffer is allocated without the main get area being present. This results in every subsequent ungetc (as the stream remains in the backup area) checking uninitialized memory in the backup buffer when trying to put a character back into the stream. Avoid comparing the input character with buffer contents when in backup to avoid this uninitialized read. The uninitialized read is harmless in this context since the location is promptly overwritten with the input character, thus fulfilling ungetc functionality. Also adjust wording in the manual to drop the paragraph that says glibc cannot do multiple ungetc back to back since with this change, ungetc can actually do this. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Make tst-ungetc use libsupportSiddhesh Poyarekar2024-08-151-55/+57
| | | | | Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* stdio-common: Add test for vfscanf with matches longer than INT_MAX [BZ #27650]Maciej W. Rozycki2024-07-262-0/+113
| | | | | | | | | | | | | | | | | | | Complement commit b03e4d7bd25b ("stdio: fix vfscanf with matches longer than INT_MAX (bug 27650)") and add a test case for the issue, inspired by the reproducer provided with the bug report. This has been verified to succeed as from the commit referred and fail beforehand. As the test requires 2GiB of data to be passed around its performance has been evaluated using a choice of systems and the execution time determined to be respectively in the range of 9s for POWER9@2.166GHz, 24s for FU740@1.2GHz, and 40s for 74Kf@950MHz. As this is on the verge of and beyond the default timeout it has been increased by the factor of 8. Regardless, following recent practice the test has been added to the standard rather than extended set. Reviewed-by: DJ Delorie <dj@redhat.com>
* Fix conditionals on mtrace-based tests (bug 31892)Carlos O'Donell2024-07-011-9/+25
| | | | | | | | | | | The conditionals for several mtrace-based tests in catgets, elf, libio, malloc, misc, nptl, posix, and stdio-common were incorrect leading to test failures when bootstrapping glibc without perl. The correct conditional for mtrace-based tests requires three checks: first checking for run-built-tests, then build-shared, and lastly that PERL is not equal to "no" (missing perl). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Revert "Test fscanf of long double without <stdio.h>"H.J. Lu2024-05-243-39/+0
| | | | | | | | This reverts commit 30a745450e01e4c6f484dc691c16a54a6ea72288. On ppc64le, without <stdio.h>, vfscanf is used and with <stdio.h> __isoc23_vfscanfieee128 is used. I am reverting this since it doesn't work on all targets.
* Test fscanf of long double without <stdio.h>H.J. Lu2024-05-243-0/+39
| | | | | | | Add a test for fscanf of long double without including <stdio.h>. Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Sunil K Pandey <skpgkp2@gmail.com>
* posix: Sync tempname with gnulibAdhemerval Zanella2024-04-108-12/+196
| | | | | | | | | | | | | | | | | | | | | | | | | The gnulib version contains an important change (9ce573cde), which fixes some problems with multithreading, entropy loss, and ASLR leak nfo. It also fixes an issue where getrandom is not being used on some new files generation (only for __GT_NOCREATE on first try). The 044bf893ac removed __path_search, which is now moved to another gnulib shared files (stdio-common/tmpdir.{c,h}). Tthis patch also fixes direxists to use __stat64_time64 instead of __xstat64, and move the include of pathmax.h for !_LIBC (since it is not used by glibc). The license is also changed from GPL 3.0 to 2.1, with permission from the authors (Bruno Haible and Paul Eggert). The sync also removed the clock fallback, since clock_gettime with CLOCK_REALTIME is expected to always succeed. It syncs with gnulib commit 323834962817af7b115187e8c9a833437f8d20ec. Checked on x86_64-linux-gnu. Co-authored-by: Bruno Haible <bruno@clisp.org> Co-authored-by: Paul Eggert <eggert@cs.ucla.edu> Reviewed-by: Bruno Haible <bruno@clisp.org>
* Rename c2x / gnu2x tests to c23 / gnu23Joseph Myers2024-02-012-2/+2
| | | | | | | 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.
* Refer to C23 in place of C2X in glibcJoseph Myers2024-02-016-16/+17
| | | | | | | | | | | | | | | 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.
* localedata: Use consistent values for grouping and mon_groupingMike FABIAN2024-01-252-4/+69
| | | | | | Resolves: BZ # 31205 Adapt test cases in test-grouping_iterator.c
* Update copyright dates with scripts/update-copyrightsPaul Eggert2024-01-01181-181/+181
|
* elf: Fix _dl_debug_vdprintf to work before self-relocationAdhemerval Zanella2023-11-212-0/+10
| | | | | | | | | | | | | The strlen might trigger and invalid GOT entry if it used before the process is self-relocated (for instance on dl-tunables if any error occurs). For i386, _dl_writev with PIE requires to use the old 'int $0x80' syscall mode because the calling the TLS register (gs) is not yet initialized. Checked on x86_64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* crypt: Remove libcrypt supportAdhemerval Zanella2023-10-301-2/+0
| | | | | | | | | | | | | | | | | | 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>
* C2x scanf %wN, %wfN supportJoseph Myers2023-09-284-0/+552
| | | | | | | | | 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.
* fxprintf: Get rid of allocaJoe Simmons-Talbott2023-08-151-8/+6
| | | | | | | Use a scratch_buffer rather than alloca/malloc to avoid potential stack overflow. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* vfprintf-internal: Get rid of alloca.Joe Simmons-Talbott2023-08-012-1/+152
| | | | | | | | | Avoid potential stack overflow from unbounded alloca. Use the existing scratch_buffer instead. Add testcases to exercise the code as suggested by Adhemerval Zanella Netto. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* vfscanf-internal: Remove potentially unbounded allocasAdhemerval Zanella2023-07-063-17/+115
| | | | | | | | | | | 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>
* Exclude routines from fortificationFrédéric Bérat2023-07-051-1/+14
| | | | | | | | | | | | | | | | | 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>
* stdio-common: tests: Incorrect maxlen parameter for swprintfFrederic Berat2023-06-222-11/+12
| | | | | | | Few tests using swprintf are passing incorrect maxlen parameter. This triggers an abort when _FORTIFY_SOURCE is enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* C2x scanf %b supportJoseph Myers2023-06-192-4/+212
| | | | | | | | | | | | ISO C2x defines scanf %b for input of binary integers (with an optional 0b or 0B prefix). Implement such support, along with the corresponding SCNb* macros in <inttypes.h>. Unlike the support for binary integers with 0b or 0B prefix with scanf %i, this is supported in all versions of scanf (independent of the standards mode used for compilation), because there are no backwards compatibility concerns (%b wasn't previously a supported format) the way there were for %i. Tested for x86_64 and x86.
* C2x printf %wN, %wfN support (bug 24466)Joseph Myers2023-06-197-15/+799
| | | | | | | | | | | | | | | | | | 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.
* tests: replace fgets by xfgetsFrederic Berat2023-06-131-7/+4
| | | | | | With fortification enabled, fgets calls return result needs to be checked, has it gets the __wur macro enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* tests: replace fread by xfreadFrederic Berat2023-06-135-9/+20
| | | | | | With fortification enabled, fread calls return result needs to be checked, has it gets the __wur macro enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* tests: fix warn unused result on asprintf callsFrédéric Bérat2023-06-063-5/+8
| | | | | | | When enabling _FORTIFY_SOURCE, some functions now lead to warnings when their result is not checked. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Fix a few more typos I missed in previous round -- BZ 25337Paul Pluzhnikov2023-06-021-1/+1
|
* Fix all the remaining misspellings -- BZ 25337Paul Pluzhnikov2023-06-026-10/+10
|
* tests: fix warn unused resultsFrédéric Bérat2023-06-013-8/+23
| | | | | | With fortification enabled, few function calls return result need to be checked, has they get the __wur macro enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* tests: replace ftruncate by xftruncateFrédéric Bérat2023-06-011-1/+2
| | | | | | | With fortification enabled, ftruncate calls return result needs to be checked, has it gets the __wur macro enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* stdio-common: Adjust tests in MakefileCarlos O'Donell2023-05-186-22/+22
| | | | | | | | | Sort tests against updated scripts/sort-makefile-lines.py. No changes in generated code. No regressions on x86_64 and i686. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* stdio-common: Reformat Makefile.Carlos O'Donell2023-05-161-10/+20
| | | | | | | | | | Reflow Makefile. Sort using 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.
* stdio-common: Fix building when !IS_IN (libc)Sergey Bugaev2023-04-031-0/+2
| | | | | | | | In this case, _itoa_word () is already defined inline in the header (see sysdeps/generic/_itoa.h), and the second definition causes an error. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230319151017.531737-11-bugaevc@gmail.com>
* 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
|
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-05 05:48:23 +0000