On Windows, std::tmpfile() returns NULL with errno 22 when %TEMP%
contains a character outside the ANSI code page, where GetTempPathA
returns '?' in its place. Fifteen tests that capture output through it
aborted. TemporaryFile::Open() opens a unique delete-on-close file under
temp_directory_path() with _wfopen; other hosts keep std::tmpfile().
Part of #13083
Co-Authored-By: Claude Opus 5.5 <[email protected]>
CheckSetvbufInvalidMode sat inside the #ifdef _WIN32 block of
CheckStandardStreamDeleteSharing while main calls it on every platform,
so the Linux build failed. It uses nothing Windows-specific: move it
above the block so the check also runs on Linux.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
GuestStandardStreams used setvbuf only with valid modes.
CheckSetvbufInvalidMode requires modes 3, -1 and INT_MAX to return EOF,
as FreeBSD's setvbuf does for any mode other than _IOFBF, _IOLBF and
_IONBF (C11 7.21.5.6: nonzero for an invalid mode). A rejected call with
a buffer must not adopt it: a character written afterwards stays out of
that buffer and the stream still writes and reads back normally.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
fputws and wprintf write a UTF-16 surrogate pair as one four-byte
UTF-8 sequence, but fgetwc decoded that sequence into a single code
point above 0xFFFF, which is not a 16-bit guest wchar_t value, and
fgetws stored it truncated: fputws(u"A\U0001F600\n") read back as
A, U+F600, newline.
fgetwc now returns the high surrogate and keeps the low one in the
stream for the next read, so fgetws stores the pair, also when the
buffer fills between the two halves. A successful seek discards it,
as FreeBSD's fseeko resets the stream's mbstate. Sequences that
decode to an overlong form or above U+10FFFF, and lead bytes F8 to
FF, fail with EILSEQ instead of returning made-up characters; the
three-byte surrogates that fputwc writes for a single unit are still
read back as that unit.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QegaHM5QeCynUQ2ZLWHE4b
On Windows the UCRT drops a write that directly follows a read on an r+,
w+ or a+ stream: fputc and fprintf report success, fwrite returns 0 and
fputs returns EOF, all without the error indicator, and the file is left
unchanged, also after an fflush. On a stream open only for reading, fputc
after a read reports success as well.
Writes now first do what FreeBSD 11.4's __swsetup does: a stream open only
for reading fails with EBADF and sets the error indicator, and an update
stream that is reading drops its read buffer and ungetc data, clears end
of file and writes at the descriptor's offset. This covers fwrite, fputs,
fputc, putc_unlocked, fprintf, fprintf_s, fputwc, fputws, fwprintf,
fwprintf_s, puts and wprintf, and printf, vprintf and printf_s, which
write to standard output through PrintWindows and now return -1 there
instead of throwing.
Linux is unchanged: glibc writes at the stream position, which the libc
technical debt now records.
The fgetws in the libc.prx that titles ship (the same 133 bytes in the
copies of PPSA13934, PPSA07923 and PPSA05916, read from disassembly)
differs from this one in two cases:
- A size below 2 returns null at once, without writing the buffer,
errno or the stream (cmp $0x2,%esi; jge, else the null result). Here a
size of 1 stored a NUL and returned the buffer, and a size of 0 or less
set the stream error and errno 22.
- When fgetwc returns -1 after characters were stored, the console
null-terminates and returns the buffer; it returns null only when
nothing was stored, and never checks ferror. Here a read error after
some characters returned null.
The rest already matches: each fgetwc result is stored as its low 16 bits
(mov %ax,(%rbx)), and the newline test compares all 32 bits. A null buffer
or stream, which the console dereferences, keeps failing with errno 22.
guest_standard_streams now expects the console results for sizes 1, 0
and -1 and for an invalid byte after a stored character; its fgetwc error
indicator check is unchanged. The libc debt entry cites the reading and
what it leaves unverified.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
On Linux sscanf, vsscanf, fscanf and sscanf_s hand their conversions to
glibc. Since glibc 2.38, code built as GNU C++ calls the C23 entry
points (__isoc23_vsscanf, __isoc23_vfscanf, __isoc23_sscanf), whose %i
reads a 0b/0B binary prefix. On main,
sscanf("0b101 x", "%i%n%7s", &value, &end, rest) stores value 5 and
end 5 and leaves "x" for the %s; " -0B11" gives -3. TechnicalDebt
records this.
FreeBSD's %i knows only the 0 and 0x prefixes. FreeBSD 11.4
lib/libc/stdio/vfscanf.c, parseint, lines 345-353 and 371-380:
case '0':
if (base == 0) {
base = 8;
flags |= PFXOK;
}
...
/* letters ok iff hex */
case 'A': case 'B': case 'C':
case 'D': case 'E': case 'F':
case 'a': case 'b': case 'c':
case 'd': case 'e': case 'f':
/* no need to fix base here */
if (base <= 10)
break; /* not legal here */
so "0b101" stores 0, consumes the "0" and leaves "b101", as C17 does
and as the strtol family here already does.
With glibc the scanf family now calls __isoc99_vsscanf and
__isoc99_vfscanf, the entry points GNU C++ used before glibc 2.38
(exported since 2.7), which read %i without the binary prefix. Other
hosts keep std::vsscanf and std::vfscanf. The TechnicalDebt entry is
removed.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
fflush() passed every stream to glibc's fflush(). For a stream that is
reading, glibc seeks the descriptor back and drops the read buffer, and
with a pushed-back character it gets the position wrong: after fgetc()
returned 'a' from "abcdef\n" and ungetc('Z'), fflush() returned 0 and
the next fread() returned "bcdef\n\n". The pushed-back 'Z' was lost and
the last byte came back twice.
FreeBSD's fflush() writes out only a stream that is writing and leaves
every other stream as it is, lib/libc/stdio/fflush.c:
if ((fp->_flags & (__SWR | __SRW)) == 0)
retval = 0;
else
retval = __sflush(fp);
and __sflush():
t = fp->_flags;
if ((t & __SWR) == 0)
return (0);
fflush() on Linux now returns 0 without calling the host for a stream
whose last operation was not a write (__fwriting() is 0). fflush(NULL)
and streams that are writing are unchanged.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Adrià