[EagleBearerYS]

What

fflush (libc/src/FileAndHeap.cpp) throws when the host flush fails, so an ordinary write error such as a full disk ends the title:

terminate called after throwing an instance of 'std::runtime_error'
  what():  fflush: flush failed

On a write error, C17 7.21.5.2 asks fflush to set the stream's error indicator and return EOF. FreeBSD's __sflush does exactly that (fflush.c L126-L137).

fflush was the one stream call left:

• fix(libc): return stream errors from fwrite, fread and fputs instead of throwing #4380 made fwrite, fread and fputs return their errors instead of throwing.
• fix(libc): return fclose failures to callers #3926 did the same for fclose.
• fix(libc): return stream errors from fwrite, fread and fputs instead of throwing #4380's description left fflush to fix(libc): leave a stream that is reading untouched in fflush on Linux #4372, which has since merged without changing the throw.

fflush now returns the host's result and syncs the guest stream's error flag, as those functions do. A stream that was already closed still throws, as the existing test expects. No title is claimed.

Tested

Windows 11 (10.0.26300), WinLibs MinGW-w64 GCC 15.2.0 r7 (UCRT), Release, -DBUILD_TESTING=ON, on main at c13dc7e:

• file_streams now writes a line into a buffered stream, then replaces the stream's descriptor with a read-only one, so the flush fails with EBADF on both hosts. fflush must return EOF, and ferror must report the error.
• With main's FileAndHeap.cpp the test ends with the terminate above. With the change it passes 20 runs in a row.
• 128 tests pass: the tests registered in core/libs/prx/libc/CMakeLists.txt and core/libs/prx/libkernel/CMakeLists.txt that build on Windows.
• tools/check_conventions.py --base origin/main passes.
• Linux: WSL2 (Ubuntu 24.04, GCC 13.3.0, Release with CI's configure flags), same commit. With main's FileAndHeap.cpp the test aborts the same way. With the change it passes 20 runs in a row.
• Not tested: macOS.
• Title: XPSemu (PPSA97358), on main 18c438b with feat(libkernel): add getdtablesize #5061 and feat(libkernel): report RLIMIT_NOFILE through getrlimit #5187 merged, stops with fflush: flush failed (0xC0000409) when its Mesa shader-cache write fails under the Windows file lock (fix(libc): make flock advisory on Windows so other descriptors can read and write #4958); with this change fflush returns the failure and the title reaches xemu's GPU probe, as babyhuey reported in fix(libc): return flush failures from fflush instead of throwing #4904 (comment).

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Unblocks: none
• AI-assisted: yes

[xXPBSXx]

Windows test: head 3d550b3de merged onto current main ea2bbefb2 (clean merge, no conflicts). Windows 10, MinGW GCC (WinLibs), Ninja Release, -j2: full build 0 errors; ctest with the filter file_streams: file_streams passed (1 test(s), 0 failed); python tools/check_conventions.py --base upstream/main passed. I did not run the new tests against main without the change.

AI-assisted (Claude Code).

[babyhuey]

Title evidence from Windows (Windows 11, RTX 3080, WinLibs GCC 15.2, Release): XPSemu (PPSA97358), on main 18c438b with #5061 and #5187 merged, relinked with --windows-fixed-base 0x400000. Its Mesa shader cache write fails with EACCES under the whole-file Windows flock (#4958), and main throws fflush: flush failed (exit 0xC0000409). With this PR (3d550b3, clean merge, without #4958) there's no throw. fflush returns the failure and Mesa carries on, so the title reaches xemu's GPU probe. Mesa treats each failed part as bad, though, and moves on through part0 to part49 with nothing stored, so #4958 is what makes the cache work.