glibc/stdio-common, 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 freopen handling of ,ccs= (bug 23675)

2024-09-05T20:08:10Z

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)

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.

Clear flags2 flags set from mode in freopen (bug 32134)

2024-09-05T11:15:29Z

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 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.

support: Use macros for *stat wrappers

2024-08-16T14:05:20Z

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

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