Hi Garret, On 2026-05-07T17:19:46-0400, Garrett Wollman wrote: > < said: > > > Later, in POSIX.1-2001, it already appears in . So, at some > > point, people decided to move it there. POSIX doesn't say anything > > about the move, though. > > Note that 1003.1-2001 (XSH page 761) shades the synopsis as "XSI" -- > this is code for "mistakes inherited from XPG4 and included as a part > of the unification of POSIX with the Single UNIX Specification". Oh, my browser doesn't open anything when I click on XSI (javascript is probably disabled for $reasons). That's the text that appears? Interesting! Thanks! So this is officially a mistake from XPG4? Anyway, that still leaves me with doubts: Were there any implementations that provided mkstemp(3) in ? If all the implementations provided it in , why wasn't the standard ignored? Why did all implementations change to accomodate to a known mistake? Or maybe the closed source Unix systems of the time did have it in ? Have a lovely night! Alex > As > the definition of (XBD page 325) notes: > > Some of the functionality described on this reference page > extends the ISO C standard. Applications shall define the > appropriate feature test macro (see the System Interfaces > volume of IEEE Std 1003.1-2001, Section 2.2, The Compilation > Environment) to enable the visibility of these symbols > in this header. > > This is shaded "CX", meaning "extension to ISO C", but all of the > noted extensions are shaded "XSI" except for posix_memalign ("ADV"), > rand_r ("TSF"), setenv and unsetenv (both "CX"). > > > So, the point where it was moved seems to have been XPG4v2 (which was > > later repackaged as SUSv1). I don't know why XPG4v2 decided to move the > > prototype from to . I've CCed kleink, in case it > > knows (and remembers). > > The "XSI" declarations in 1003.1-2001 for are: > > All symbols from , , , and > (at the implementation's option). > > The W* constants from for use with wait3(). > > The functions a64l(), drand48(), ecvt(), erand48(), fcvt(), > gcvt(), getsubopt(), grantpt(), initstate(), jrand48(), > l64a(), lcong48(), lrand48(), mktemp() [marked "LEGACY"], > mkstemp(), mrand48(), nrand48(), posix_openpt(), ptsname(), > putenv(), random(), realpath(), seed48(), setkey(), > setstate(), srand48(), srandom(), and unlockpt(). > > This is really quite a motley list: PRNGs, ASCII-numeric conversion > routines, temporary files, environment variables, pseudo-TTYs, and the > constants for wait3() but not the wait3() functon itself. > > The "XSI" option is unusual in POSIX in that its interfaces need not > be declared unless the application has defined the appropriate > _XOPEN_SOURCE macro. (In real-world implementations, these interfaces > are normally declared by default unless the application has requested > a stricter namespace with _POSIX_C_SOURCE or similar.) > > POSIX also has a very weird attitude toward compatibility with > previous (or future) revisions of itself; the standard says nothing > about how an application written for C99 can be compiled on an > 1003.1:2024 system -- as far as the current standard is concerned, the > only compiler is C17.[1] Many implementations, however (including the > work I did for FreeBSD back in the early 2000s) attempt to support > source and binary compatibility with multiple standards and with > traditional (pre-standard) applications, to the extent feasible with > preprocessor macros and the development tools available. > > -GAWollman > > [1] Why is 1003.1:2024 not aligned with C23? Because the work on the > 2024 standard started in 2018, and POSIX as currently specified both > subsumes and defers to a specific ISO C standard; the Austin Group > couldn't align to C23 until we knew officially what was going to be in > it and that it was going to be fully approved and published *before* > POSIX went into balloting with IEEE and ISO. The next POSIX will be > aligned with C23. --