mkstemp(3)

mkstemp(3)

[Douglas McIlroy]

The synopses of mkstemp(3) that I have seen, e.g. in ubuntu 13.3.0,
say incorrectly that it is declared in <stdlib.h>. It is not in gcc's
<stdlib.h>, and should not be, because stdlib.h is part of the C
standard and mkstemp is a construct of Unix, not C. (It returns a file
descriptor.)

Doug McIlroy

Re: mkstemp(3)

[Alejandro Colomar]

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

Hi Doug,

On 2026-05-07T13:22:44-0400, Douglas McIlroy wrote:
> The synopses of mkstemp(3) that I have seen, e.g. in ubuntu 13.3.0,
> say incorrectly that it is declared in <stdlib.h>.

That's conforming to POSIX.

	$ MANWIDTH=64 man 3posix mkstemp | head -n20
	MKSTEMP(3POSIX)    POSIX Programmer’s Manual    MKSTEMP(3POSIX)

	PROLOG
	     This manual page is part of the POSIX Programmer’s Manual.
	     The  Linux  implementation  of  this  interface may differ
	     (consult the corresponding Linux manual page  for  details
	     of  Linux  behavior),  or  the interface may not be imple‐
	     mented on Linux.

	NAME
	     mkstemp —— create a unique file

	SYNOPSIS
	     #include <stdlib.h>

	     int mkstemp(char *template);

	DESCRIPTION
	     Refer to mkdtemp().

<https://pubs.opengroup.org/onlinepubs/9799919799/functions/mkdtemp.html>

> It is not in gcc's
> <stdlib.h>, and should not be, because stdlib.h is part of the C
> standard and mkstemp is a construct of Unix, not C. (It returns a file
> descriptor.)

It really is in <stdlib.h>.

	alx@devuan:~$ grepc mkstemp /usr/include/
	/usr/include/stdlib.h:extern int mkstemp (char *__template) __nonnull ((1)) __wur;
	/usr/include/stdlib.h:#   define mkstemp mkstemp64

However, it is hidden behind preprocessor macros that enable it only
when POSIX extensions are enabled:

	$ man -w mkstemp | MANWIDTH=64 xargs mansectf SYNOPSIS | cat;
	mkstemp(3)          Library Functions Manual         mkstemp(3)

	SYNOPSIS
	     #include <stdlib.h>

	     int mkstemp(char *template);
	     int mkostemp(char *template, int flags);
	     int mkstemps(char *template, int suffixlen);
	     int mkostemps(char *template, int suffixlen, int flags);

	 Feature   Test   Macro   Requirements   for  glibc  (see  fea‐
	 ture_test_macros(7)):

	     mkstemp():
		 _XOPEN_SOURCE >= 500
		     || /* glibc >= 2.12: */ _POSIX_C_SOURCE >= 200809L
		     || /* glibc <= 2.19: */ _SVID_SOURCE || _BSD_SOURCE

	     mkostemp():
		 _GNU_SOURCE

	     mkstemps():
		 /* glibc >= 2.19: */ _DEFAULT_SOURCE
		     || /* glibc <= 2.19: */ _SVID_SOURCE || _BSD_SOURCE

	     mkostemps():
		 _GNU_SOURCE

	Linux man‐pages 6.18‐16... 2026‐02‐08                mkstemp(3)

This is, because as you say, ISO C doesn't allow that identifier to be
declared in <stdlib.h>.

I guess the reason this is in <stdlib.h> is due to Historical
Reasons (TM).

Interestingly, the function first appeared in 4.3BSD, but it had no
header: the user had to declare it manually.  Later, in 4.4BSD, it was
provided in <unistd.h> (which is the usual header where you'd expect
it).  I don't see the function in POSIX.1-1990, so I guess SysVr4 didn't
have it yet.

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.

FreeBSD provides it in both.
Here's the commit that added it to <stdlib.h>:

	commit 3ecc48e2ea69c322abc93ef02f1b7eadac73b774
	Author: Garrett Wollman <wollman@FreeBSD.org>
	Date:   2002-09-21 02:03:58 +0000

	    Use new visibility macros.  Reorder some disordered declarations.  Add
	    new 1003.1-2001 declarations, commented out in cases where we do not
	    implement the function.  Note that strtoq() and strtouq() are slated
	    for deletion in 6.0.  (2 of 5)

While the <unistd.h> declaration comes from 4.4BSD-Lite:

	commit 59deaec541ae8baaa58daf6c5a2196ea7de180c3
	Author: Rodney W. Grimes <rgrimes@FreeBSD.org>
	Date:   1994-05-24 09:57:34 +0000

	    BSD 4.4 Lite Include Sources

It doesn't tell much.  NetBSD has some more information:

	commit 9b9e2550519f0e7c0cb730c9c3c95137dc14c314
	Author: kleink <kleink@NetBSD.org>
	Date:   1998-06-01 20:10:15 +0000

	    * Further name space protection reorganization: distinguish between various
	      issues of the XPG.
	    * Move setkey() prototype from <unistd.h> to this file. (XPG4)
	    * Move mkstemp(), mktemp(), ttyslot() and valloc() prototypes from <unistd.h>
	      to this file. (XPG4.2)

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).


Have a lovely night!
Alex

> 
> Doug McIlroy

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

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

Re: mkstemp(3)

[Garrett Wollman]

<<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".  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.

Re: mkstemp(3)

[Alejandro Colomar]

[-- 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 --]

Re: mkstemp(3)

[Douglas McIlroy]

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 <wollman@bimajority.org> 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".  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.

Re: mkstemp(3)

[Garrett Wollman]

<<On Thu, 7 May 2026 21:34:03 -0400, Douglas McIlroy <douglas.mcilroy@dartmouth.edu> said:

> 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.

<div class="standards-lawyering">
Conveniently, POSIX.1-2008 removed mkstemp from the XSI option and
made it standard (shaded only CX and not XSI) so in 2008 and newer,
you don't have to define _XOPEN_SOURCE.  You do have to set the
correct _POSIX_C_SOURCE value for the standard your implementation
confirms to, which currently means that you can only use C17 in
POSIX.1-2024 and cannot use C23 at all.

This may be the source of the confusion: for ISO C, "the
implementation" is the compiler, header files, and standard library,
so your C23 compiler ships with versions of those that meet the
requirements of the C23 standard.  For POSIX on the other hand, "the
implementation" is the entire operating system, which must support one
and only one specific version of ISO C.  It is up to your operating
system supplier (e.g. Linux distro packager) to build a <stdlib.h>
that meets the requirements of POSIX if they want to claim to be
POSIX-compliant.  (Very likely they don't actually care about formal
compliance.)

An application that uses C23 features (or indeed that is compiled with
anything other than the POSIX.1-2024 `c17` utility) is not a
conforming POSIX application and its behavior is undefined.  (Likewise
POSIX.1-2008 requires compilation with the `c99` utility, since that
standard is aligned to C99.)
</div>

-GAWollman

Re: mkstemp(3)

[Alejandro Colomar]

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

Hi Doug, Garrett,

On 2026-05-07T22:32:30-0400, Garrett Wollman wrote:
> <<On Thu, 7 May 2026 21:34:03 -0400, Douglas McIlroy <douglas.mcilroy@dartmouth.edu> said:
> 
> > 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.

It is mentioned in this part (see the bottom of the SYNOPSIS):

	 Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

	     mkstemp():
		 _XOPEN_SOURCE >= 500
		     || /* glibc >= 2.12: */ _POSIX_C_SOURCE >= 200809L
		     || /* glibc <= 2.19: */ _SVID_SOURCE || _BSD_SOURCE

To be honest, I've never liked that format too much, and think it would
be more readable as this:

		#define _XOPEN_SOURCE  500
		#include <stdlib.h>

		int mkstemp(char *template);

> <div class="standards-lawyering">
> Conveniently, POSIX.1-2008 removed mkstemp from the XSI option and
> made it standard (shaded only CX and not XSI) so in 2008 and newer,
> you don't have to define _XOPEN_SOURCE.  You do have to set the
> correct _POSIX_C_SOURCE value for the standard your implementation
> confirms to,

Hmmm, I should probably give more preference to _POSIX_C_SOURCE in the
manual page.  Thanks!

> which currently means that you can only use C17 in
> POSIX.1-2024 and cannot use C23 at all.

Well, you could technically ask for a combination of both, by doing:
-D_POSIX_C_SOURCE=200809L -std=c23.  Then it's up to the compiler and
libc to decide what to do with such a petition, but since POSIX usually
only adds ISO C-compatible APIs, it shouldn't be problematic.

> This may be the source of the confusion: for ISO C, "the
> implementation" is the compiler, header files, and standard library,
> so your C23 compiler ships with versions of those that meet the
> requirements of the C23 standard.  For POSIX on the other hand, "the
> implementation" is the entire operating system, which must support one
> and only one specific version of ISO C.  It is up to your operating
> system supplier (e.g. Linux distro packager) to build a <stdlib.h>
> that meets the requirements of POSIX if they want to claim to be
> POSIX-compliant.  (Very likely they don't actually care about formal
> compliance.)
> 
> An application that uses C23 features (or indeed that is compiled with
> anything other than the POSIX.1-2024 `c17` utility) is not a
> conforming POSIX application and its behavior is undefined.  (Likewise
> POSIX.1-2008 requires compilation with the `c99` utility, since that
> standard is aligned to C99.)
> </div>

Interestingly, c99(1) is defined by POSIX to only need to accept an
ISO C-conforming program, and thus it doesn't support POSIX interfaces
added to <stdlib.h>.  I'm not sure if this is intentional.

	alx@devuan:~/tmp$ cat test.c 
	#include <stdlib.h>

	int
	main(void)
	{
		mkstemp("foo");
	}
	alx@devuan:~/tmp$ c99 test.c 
	test.c: In function ‘main’:
	test.c:6:9: error: implicit declaration of function ‘mkstemp’ [-Wimplicit-function-declaration]
	    6 |         mkstemp("foo");
	      |         ^~~~~~~

This is with GCC and glibc.  I don't have c17(1) in my system; maybe GCC
has not cared to add it.


Have a lovely day!
Alex

> -GAWollman

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

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