https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127424
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jonathan Wakely <[email protected]>: https://gcc.gnu.org/g:819afc442bd1e1b38f60fad174d80f677ab86bf0 commit r17-4396-g819afc442bd1e1b38f60fad174d80f677ab86bf0 Author: Gökbey Keskin <[email protected]> Date: Wed Sep 16 17:47:08 2026 +0100 libstdc++: Fix tests that open FIFOs with O_RDWR [PR127424] Several tests under 27_io open a FIFO with ios_base::in|ios_base::out, which fopen_mode() maps to "r+", i.e. O_RDWR. POSIX leaves this undefined: O_RDWR Open for reading and writing. The result is undefined if this flag is applied to a FIFO. Linux permits it, so the problem is invisible there, but it is not required. On a target where opening a FIFO O_RDWR fails, the affected tests deadlock: the process that issues the O_RDWR open fails to open the FIFO, so its peer blocks forever in a blocking open() for the opposite direction, because the FIFO never acquires a second endpoint. None of these tests needs read-write access. In every case the process opening in|out only ever writes. Opening write-only replaces the O_RDWR open with the ordinary FIFO rendezvous (child O_WRONLY, parent O_RDONLY, or vice versa), which is fully specified and introduces no ordering hazard. Second, separate issue: close/char/9964.cc has not tested PR 9964 since 2004. PR libstdc++/9964 was fixed by Petur Runolfsson in r0-48647-g0c45b8e0733816 so that basic_filebuf::close() always closes the file even if it returns null to indicate an error. The test as originally committed opened the parent end write-only and asserted exactly that: filebuf* ret = fb.open(name, ios_base::out | ios_base::trunc); ... ret = fb.close(); VERIFY( ret == NULL ); VERIFY( !fb.is_open() ); The write-only open is what makes the flush fail: the child closes the sole read end, the parent's buffered 'a' meets a FIFO with no readers, SIGPIPE is ignored, and write() fails with EPIPE. r0-56237-g6a734d618f8 (2004-02-04, "Correct flags to filebuf::open calls", the commit that introduced fopen_mode) changed both the mode and the expectation: - filebuf* ret = fb.open(name, ios_base::out | ios_base::trunc); + filebuf* ret = fb.open(name, ios_base::in | ios_base::out); ... - VERIFY( ret == NULL ); + VERIFY( ret != NULL ); With O_RDWR the parent holds its own read end, so the write at close succeeds and the failure path is never entered. The test now passes whether or not the PR 9964 fix is present, i.e. it is a dead regression test. So the fix for this file is to restore the original write-only open and the original close() expectation, which also removes its O_RDWR dependency. libstdc++-v3/ChangeLog: PR libstdc++/127424 * testsuite/27_io/basic_filebuf/close/char/9964.cc: Only open filebuf for output and expect close() to return null. * testsuite/27_io/basic_filebuf/seekoff/char/26777.cc: Only open filebuf for output. * testsuite/27_io/basic_filebuf/showmanyc/char/9533-1.cc: Likewise. * testsuite/27_io/basic_filebuf/underflow/char/10097.cc: Likewise. * testsuite/27_io/objects/char/7.cc: Likewise. * testsuite/27_io/objects/char/9661-1.cc: Only open FILE for output.
