[Kikoarl]

What

On Windows, after a stream reaches end-of-file, the host C runtime reads again on every call, returning newly appended bytes without a clearerr. FreeBSD 11.4 refill.c keeps returning EOF while __SEOF is set until clearerr, a seek or ungetc.

Keep returning EOF from fgetc, getc, fgets, fread and fscanf while the stream is at end-of-file. fscanf determines its result at end-of-file from the first format directive matching FreeBSD vfscanf.c. Document %n and host ungetc limitations in TechnicalDebt.md.

Closes #5279

Tested

• Linux (x86_64), GCC 16, Release, RAM-disk build (/tmp/anyps5_build).
• Passes ctest -R "^guest_standard_streams$": exercises CheckStickyEndOfFile across fgetc, getc_unlocked, fgets, fread, clearerr, fseeko and fscanf.
• Passes ctest -R "^file_streams$".
• Passes python3 tools/check_conventions.py.

Checklist

• Description explains the problem and the change
• PR follows CONTRIBUTING.md
• Changes are covered by tests
• Code passes python3 tools/check_conventions.py
• Tech debt documented in docs/dev/TechnicalDebt.md (if applicable)
• AI-assisted: yes
• Depends on: none

[github-actions]

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
#4627	core/libs/prx/libc/src/StandardStreams.cpp L42
#5285	core/libs/prx/libc/src/Formatting.cpp L11
#5291	core/libs/prx/libc/src/Formatting.cpp L11

[LeandroLP23]

Windows check: Windows 11 (26300), WinLibs GCC 15.2.0, Release, head f9a39133c merged onto main 30f961266.

• With the PR: guest_standard_streams passes.
• With main's libc/src/FileAndHeap.cpp, Formatting.cpp and StandardStreams.cpp and the PR's test: it fails. The test's Require aborts (exit 0xc0000409), so reading newly appended data after end-of-file still succeeds there on Windows.

Note: #5282 extends the same tests/GuestStandardStreams.cpp and libc/src/FileAndHeap.cpp, so whichever merges second will likely need a rebase.

AI-assisted: yes (Claude Code)

[CnRJay]

Heads-up for reviewers: this is the same change as #5222, husseinkad's own PR for the same fix, opened two hours earlier. This PR is a squash of #5222's four commits, with husseinkad still the author. #5222 has an empty description but the full branch, and this one has the description and LeandroLP23's Windows check. Only one can merge. It would help if the two authors agreed which continues and closed the other, with the description and test evidence carried over if #5222 is the one kept.

[oneandonlydean]

Closing: no title is known to reach this. With the queue at 700+ open PRs, please hold off on new PRs that don't name a title needing the change until it's down. If a title stops on this on current main, reopen with the title ID and the log line.