Re: mkstemp(3)

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4312 bytes --]

Hi Garret,

On 2026-05-07T17:19:46-0400, Garrett Wollman wrote:
> <<On Thu, 7 May 2026 22:23:01 +0200, Alejandro Colomar <alx@kernel.org> said:
> 
> > Later, in POSIX.1-2001, it already appears in <stdlib.h>.  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 <stdlib.h>?  If all the implementations
provided it in <unistd.h>, 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 <stdlib.h>?


Have a lovely night!
Alex

>  As
> the definition of <stdlib.h> (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 <unistd.h> to <stdlib.h>.  I've CCed kleink, in case it
> > knows (and remembers).
> 
> The "XSI" declarations in 1003.1-2001 for <stdlib.h> are:
> 
> 	All symbols from <stddef.h>, <limits.h>, <math.h>, and
> 	<sys/wait.h> (at the implementation's option).
> 
> 	The W* constants from <sys/wait.h> 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.

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]