Re: mkstemp(3)

Alejandro Colomar <[email protected]> Fri, 8 May 2026 14:33:51 +0200
Newsgroups	org.kernel.vger.linux-man
Message-ID	<af2KFQI7aPjcyMMq@devuan>
Hi Doug, Garrett,

On 2026-05-07T22:32:30-0400, Garrett Wollman wrote:
> <<On Thu, 7 May 2026 21:34:03 -0400, Douglas McIlroy <[email protected]> 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>
signature.asc (application/pgp-signature, 833 B)