<<On Thu, 7 May 2026 22:23:01 +0200, Alejandro Colomar [off-list ref] 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.