glibc/stdio-common/Makefile, branch vdso

Add a new fwrite test for memory streams

2024-09-09T18:58:07Z

Ensure that fwrite() behaves correctly when using memory streams. Reviewed-by: Carlos O'Donell

Add a new fwrite test for read-only streams

2024-09-09T17:32:20Z

Ensure that fwrite() behaves correctly even when the stream is read-only. Reviewed-by: Carlos O'Donell

Fix memory leak on freopen error return (bug 32140)

2024-09-05T11:16:59Z

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.

fgets: more tests

2024-09-04T20:24:12Z

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

Add more thorough tests of freopen

2024-09-04T16:32:21Z

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 getline

2024-08-21T19:58:14Z

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.

ungetc: Fix backup buffer leak on program exit [BZ #27821]

2024-08-15T17:56:13Z

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 Reviewed-by: Carlos O'Donell

stdio-common: Add test for vfscanf with matches longer than INT_MAX [BZ #27650]

2024-07-26T12:21:34Z

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

Fix conditionals on mtrace-based tests (bug 31892)

2024-07-01T15:20:30Z

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

Revert "Test fscanf of long double without "

2024-05-24T23:24:49Z

This reverts commit 30a745450e01e4c6f484dc691c16a54a6ea72288. On ppc64le, without , vfscanf is used and with __isoc23_vfscanfieee128 is used. I am reverting this since it doesn't work on all targets.