Re: mkstemp(3)

Aha. For maximum safety, my default configuration for gcc is very
stringent and includes -std=c2x, which apparently hides non-C-standard
parts of header files.

Posix System Interfaces Section 2.2 tells me that I should #define
_POSIX_C_SOURCE before #include <stdlib.h>. That fact is missing from
Linux's man 3 mkstemp.  Arguably the Posix description of mkstemp
should mention it, too.

Unfortunately, stdlib.h for gcc 13.3.0 does not check _POSIX_C_SOURCE,
so it looks like I may have a complaint about Gnu/Linux, too.

Doug


On Thu, May 7, 2026 at 5:19 PM Garrett Wollman <[email protected]> wrote:
>
> <<On Thu, 7 May 2026 22:23:01 +0200, Alejandro Colomar <[email protected]> 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".  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.