man/man2/*: Update history of syscalls A-CH

Heya all,

Continuing the updating of HISTORY sections, this patch set regards system calls whose identifiers start with A through CH. This time, more care was taken to ensure any modified lists are given in a somewhat chronological order.

As hinted at previously on this list, searching for a *truely* chronological ordering is likely a futile effort given the seemingly circular influences between many early systems. But an approximation of this ordering based on our limited information can still be useful. Which is the attitude with which these patches were made.

And on another note, I think I've found a way to stop Proton Mail from corrupting patches. So my patches should henceforth all be PGP-signed, assuming my workaround is sufficient.

Seth McDonald (19):
man/man2/access.2: HISTORY: Update first POSIX appearance of access(2) man/man2/access.2: HISTORY: Specify different access(2) prototypes man/man2/access.2: HISTORY: Update first POSIX appearance of
faccessat(2)
man/man2/alarm.2: HISTORY: Update first POSIX appearance of alarm(2) man/man2/chdir.2: HISTORY: Split chdir(2) and fchdir(2) man/man2/chdir.2: HISTORY: Update first POSIX appearance of chdir(2) man/man2/chdir.2: HISTORY: Specify different chdir(2) prototypes man/man2/chdir.2: HISTORY: Update first POSIX appearance of fchdir(2) man/man2/chmod.2: HISTORY: Split chmod(2) and fchmod(2) man/man2/chmod.2: HISTORY: Update first POSIX appearance of chmod(2) man/man2/chmod.2: HISTORY: Specify different chmod(2) prototypes man/man2/chmod.2: HISTORY: Update first POSIX appearance of fchmod(2) man/man2/chmod.2: HISTORY: Update first POSIX appearance of
AT_SYMLINK_NOFOLLOW
man/man2/chown.2: HISTORY: Split chown(2), fchown(2), and lchown(2) man/man2/chown.2: HISTORY: Update first POSIX appearance of chown(2) man/man2/chown.2: HISTORY: Specify different chown(2) prototypes man/man2/chown.2: HISTORY: Update first SUS appearance of fchown(2) man/man2/chown.2: HISTORY: Update first POSIX appearance of lchown(2) man/man2/chroot.2: HISTORY: Update first SUS appearance of chroot(2)

 man/man2/access.2 | 14 ++++++++++++--
 man/man2/alarm.2  |  4 +++-
 man/man2/chdir.2  | 20 +++++++++++++++++++-
 man/man2/chmod.2  | 18 ++++++++++++++++--
 man/man2/chown.2  | 24 +++++++++++++++++++++---
 man/man2/chroot.2 |  5 ++++-
 6 files changed, 75 insertions(+), 10 deletions(-)

Range-diff against v0:

 -:  ------------ >  1:  58a0a70c6308 man/man2/access.2: HISTORY: Update first POSIX appearance of access(2)
 -:  ------------ >  2:  d87c7800e0f5 man/man2/access.2: HISTORY: Specify different access(2) prototypes
 -:  ------------ >  3:  7e6b054be57e man/man2/access.2: HISTORY: Update first POSIX appearance of faccessat(2)
 -:  ------------ >  4:  51224c3d2e6c man/man2/alarm.2: HISTORY: Update first POSIX appearance of alarm(2)
 -:  ------------ >  5:  c6961e073ad1 man/man2/chdir.2: HISTORY: Split chdir(2) and fchdir(2)
 -:  ------------ >  6:  61d257dc5032 man/man2/chdir.2: HISTORY: Update first POSIX appearance of chdir(2)
 -:  ------------ >  7:  b367400491b2 man/man2/chdir.2: HISTORY: Specify different chdir(2) prototypes
 -:  ------------ >  8:  d6316545d253 man/man2/chdir.2: HISTORY: Update first POSIX appearance of fchdir(2)
 -:  ------------ >  9:  ce5b927c6695 man/man2/chmod.2: HISTORY: Split chmod(2) and fchmod(2)
 -:  ------------ > 10:  de87aa2b3e28 man/man2/chmod.2: HISTORY: Update first POSIX appearance of chmod(2)
 -:  ------------ > 11:  02eef8835d60 man/man2/chmod.2: HISTORY: Specify different chmod(2) prototypes
 -:  ------------ > 12:  691b1ee71099 man/man2/chmod.2: HISTORY: Update first POSIX appearance of fchmod(2)
 -:  ------------ > 13:  bc1d06a06e9e man/man2/chmod.2: HISTORY: Update first POSIX appearance of AT_SYMLINK_NOFOLLOW
 -:  ------------ > 14:  2981d5702b65 man/man2/chown.2: HISTORY: Split chown(2), fchown(2), and lchown(2)
 -:  ------------ > 15:  fccd134bc9d7 man/man2/chown.2: HISTORY: Update first POSIX appearance of chown(2)
 -:  ------------ > 16:  ece23c04dc89 man/man2/chown.2: HISTORY: Specify different chown(2) prototypes
 -:  ------------ > 17:  bf9099a04c4f man/man2/chown.2: HISTORY: Update first SUS appearance of fchown(2)
 -:  ------------ > 18:  5abf94a520b5 man/man2/chown.2: HISTORY: Update first POSIX appearance of lchown(2)
 -:  ------------ > 19:  fd08b4cf0a52 man/man2/chroot.2: HISTORY: Update first SUS appearance of chroot(2)

base-commit: 91fa6d909b1171bc2361b5b2192c11c8be06a7d1

2.47.3

access(2) first appeared in POSIX.1-1988.[1]

[1] IEEE Std 1003.1-1988, Section 5.6.3 "File Accessibility".

---
 man/man2/access.2 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

index 2148a896d561..1ef65a982f04 100644
@@ -332,7 +332,9 @@ .SH STANDARDS
 .SH HISTORY
 .TP
 .BR access ()
-SVr4, 4.3BSD, POSIX.1-2001.
+4.3BSD,
+SVr4,
+POSIX.1-1988.
 .TP
 .BR faccessat ()
 Linux 2.6.16,

2.47.3

access(2) was specified in POSIX.1-1988 with the prototype int access(char *path, int amode); [1]

POSIX.1-1990 then changed the prototype to
int access(const char *path, int amode); [2]

[1] IEEE Std 1003.1-1988, Section 5.6.3 "File Accessibility".
[2] IEEE Std 1003.1-1990, Section 5.6.3 "Check File Accessibility".

---
 man/man2/access.2 | 7 +++++++
 1 file changed, 7 insertions(+)

index 1ef65a982f04..c0bcf016ae5c 100644
@@ -342,6 +342,13 @@ .SH HISTORY
 .TP
 .BR faccessat2 ()
 Linux 5.8.
+.P
+POSIX.1-1988 initially specified the function signature of
+.BR access ()
+with a non-const-qualified
+.I path
+parameter.
+This was remedied in POSIX.1-1990.
 .SH NOTES
 .BR Warning :
 Using these calls to check if a user is authorized to, for example,

2.47.3

Hi Seth,

I suspect this is common to all APIs specified in those standards, right? Or is it specific to this API?

'const' was invented by ANSI C89, so I expect the change was around that time.

On the change itself, it wasn't a breaking change: programs written before the addition of const wouldn't notice that const has been added to the prototype.

The change would be noticed by a program written today, but compiled in such an old system. However, I expect such a program to be aware that pre-ANSI C was different, and it would have to adapt to it anyway. const would be something that would have to be globally ignored, with something like

	#define const

Given this should be of no importance to users, I'd prefer not documenting this difference.

What do you think?

Cheers,
Alex

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

I believe the qualifier is indeed absent from any* specified prototype in POSIX.1-1988. Which would make sense if it was first specified in C89. Similar to how void pointers didn't first appear in POSIX.1-1988, but after being added in C89, appeared in POSIX.1-1990.

*Interestingly enough, the appendix of POSIX.1-1988 (section B.2.2.4, page 192) does acknowledge the const qualifier when describing the C Standard's atoi(3) function. Which makes me think that POSIX was actually aware of C89's upcoming additions to the language. Which in turn begs the question: why, if they knew about it, was it not used in the POSIX.1-1988 standard? Multiple other types and functions were included in POSIX.1-1988 because they were (going to be) in C89.

This is just me thinking out loud here. I don't mind if the answer isn't known. Although if the answer is relevant/broad enough, it may be useful to mention it in standards(7). Something like "POSIX.1-1988 attempted to align its specification with the features/syntax of the (not yet released) C89 standard, but for ABC reasons, could not use XYZ language features."

It's important to note that since the type 'const char*' is a pointer to a const char, rather than a const pointer to a char, the type is incompatible with its non-const counterpart. That is, 'const char*' and 'char*' are technically incompatible datatypes.

This can be seen by attempting to compile the following C program:

	#include <stdio.h>

	int say_hi(const char* str)
	{
		return printf("Hi %s", str);
	}

	int main(void)
	{
		int (*func)(char*) = say_hi;
		func("Linux");
		return 0;
	}

On GCC at least, you should get an incompatible-pointer-types error.

Now imagine an old program that was built to be compatible with specifically POSIX.1-1988, and which liked to use function pointers a little too much. If it happened to use function pointers to functions whose parameters weren't const-qualified in POSIX.1-1988, but were in later versions, then it (to my understanding) cannot be linked to an implementation of a later POSIX version without either errors or the possibility of undefined behaviour.

While I cannot guarantee that such a program exists, what I can say is that I have used pointers to library functions in my own code before. So I don't think it'd be unusual for such a program to exist.

Given this, I do think this still may be notable enough to document. Perhaps not in every such function - as that can get quite repetitive - but instead as a property of the POSIX.1-1988 standard as a whole. But feel free to let me know if there's something I missed here.

Take care,
	Seth McDonald.

On-list:  2336 E8D2 FEB1 5300 692C  62A9 5839 6AD8 9243 D369
Off-list: 82B9 620E 53D0 A1AE 2D69  6111 C267 B002 0A90 0289

Hi Seth,

I don't know the year in which const was added to the C89 drafts, but I suspect it was near the release.

The C89 rationale says:

	The syntax and semantics of const were adapted from C++;
	the concept itself has appeared in other languages.

Also, qualifier rules were made more strict near the release of C89, as they discovered the dangers of assigning a 'char**' to a 'const char**' near the release. C++ had more time to investigate the issue before C++98, and so the came up with the better rules they have.

C2y will likely adopt the C++ rules for qualifiers, as proposed (by me) in n3749 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3749.txt>.
We will vote this in a month or two.

And after we vote n3749, we want to improve the rules even further, as proposed by Chris Bazley in n3674
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3674.pdf>.

We might need a qualifiers(7) manual page. Especially, once their rules are modified in ISO C2y. Alternatively, we may need a new section man3qual, with an intro(3qual) page talking about this, and then const(3qual) and volatile(3qual) to document the usual qualifiers, plus a restrict(3qual) documenting how irremediably broken that monster is, and _Atomic(3qual) also documenting that qualifier (which I never really understood well, and from what the committee is talking now, they don't seem to like it either).

I suspect back then this was not a big problem.

Function prototypes were also invented by C89 (although it seems to have been invented in an earlier draft than const, by the fact that POSIX.1-1988 has prototypes but not const).

Before function prototypes, functions were declared as

	int f();

and function pointers were declared as

	int (*fp)();

For example, here's how qsort(3) was implemented in 4.3BSD (1986):

	alx@devuan:~/src/unix/unix/4.3BSD$ cat ./usr/src/lib/libc/gen/qsort.c \
	| sed -n \
		-e '/^qsort/,/^{/p' \
		-e '/compar\>/p' \
		-e '/qcmp/p' \
		-e '/^}/{p;q}' \
	| uniq;
	static  int		(*qcmp)();		/* the comparison routine */
	qsort(base, n, size, compar)
		char	*base;
		int	n;
		int	size;
		int	(*compar)();
	{
		qcmp = compar;
			if (qcmp(j, lo) > 0)
			while (qcmp(hi -= qsz, min) > 0)
	}

Even though in 1988 function prototypes already existed, I expect code didn't start using them quickly, and thus no real incompatibilities existed.

About when function prototypes were introduced... POSIX.1-1988 already uses them, and SVID Issue 2 (~1986) doesn't, so it was somewhere between those years.

Have a lovely day!
Alex

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

BTW, there's a git repository that includes all of the historic Unix
systems: <[email protected]:dspinellis/unix-history-repo.git>

I use it when I need to inspect old Unix sysmtems. I have checked out a few of them in separate git-worktree(1)'s:

	alx@devuan:~/src/unix/unix$ ls -a
	.  ..  .bare.git  4.3BSD  v3  v4  v5  v6  v7
	alx@devuan:~/src/unix/unix$ ls | xargs -I {} git -C {} status
	HEAD detached at BSD-4_3
	nothing to commit, working tree clean
	HEAD detached at Research-V3
	nothing to commit, working tree clean
	HEAD detached at Research-V4
	nothing to commit, working tree clean
	HEAD detached at Research-V5
	nothing to commit, working tree clean
	HEAD detached at Research-V6
	nothing to commit, working tree clean
	HEAD detached at Research-V7
	nothing to commit, working tree clean

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

Hi Alex,

[...]

I'd be down for a qualifiers(7) man page. Don't know about a whole man3qual section though. Unlike library functions (man3), constants (man3const), or types (man3type), which are all provided by GNU/Linux, qualifiers are a built-in language feature of C. One could argue that GCC 'provides' them, but I don't think that means they should be documented as if they're a feature of GNU/Linux. Documenting them in the miscellaneous man7 instead conveys how they're important enough to document and are related to GNU/Linux, without implying that they're part of/provided by GNU/Linux (like other man3* sections).

Btw, I'm curious as to why you say the restrict qualifier is broken. I'm yet to encounter much trouble with it, so I'd be interested in its flaws.

[...]

[...]

[...]

So if I understand correctly, because function prototypes were first specified in C89, programs written about 1988-1990 for compatability with POSIX.1-1988 likely didn't use function pointers in the way my example did. In that case, I would agree that this change from 'char*' to 'const char*' is too inconsequential to document here.

But I do still find it an interesting clue as to how these different standards developed in tandem with one another. Perhaps we could still consider noting it in standards(7)? Since that page already documents how some systems/standards influenced each other in their historical development.

Take care,
	Seth McDonald.

On-list:  2336 E8D2 FEB1 5300 692C  62A9 5839 6AD8 9243 D369
Off-list: 82B9 620E 53D0 A1AE 2D69  6111 C267 B002 0A90 0289

[CC += gcc@]

Hi Seth,

On Wed, Jan 21, 2026 at 06:12:45AM +0000, Seth McDonald wrote:
[...]

We have _Countof(3), _Maxof(3), and _Minof(3) manual pages for these operators (which are also built-in language features (operators) of C.

And we have manual pages for attributes (man3attr).

man3qual would be smaller (the number of qualifiers is rather small), but it would be consistent, I think.

The fact that qualifiers are so widespread and unified today that there's not much variance among implementations doesn't mean that there aren't outliers. Some implementations (dialects) of C still don't have qualifiers; an example is Plan9's C compiler, which doesn't have const.

So, const is indeed a feature of GCC (among many others).

For a starter, it doesn't follow the usual qualifier rules; being a qualifier on the pointer, it gets discarded immediately on lvalue conversion. It essentially behaves as an attribute with the syntax of a qualifier.

Regarding the semantics, it's defined in terms of accesses, and thus it is valid to declare two aliasing pointers as restrict as long as they are not accessed.

	alx@devuan:~/tmp$ cat restrict.c 
	int *f(int *restrict a, int *restrict b);

	int
	main(void)
	{
		int x;

		f(&x, &x);
	}

	int *
	f(int *restrict a, int *restrict b)
	{
		*a = 42;
		return b;
	}
	alx@devuan:~/tmp$ gcc -Wall -Wextra restrict.c 
	restrict.c: In function ‘main’:
	restrict.c:8:11: warning: passing argument 1 to ‘restrict’-qualified parameter aliases with argument 2 [-Wrestrict]
	    8 |         f(&x, &x);
	      |           ^~  ~~

The program above is fine according to ISO C. GCC diagnoses in this case (it is a false positive), but doesn't diagnose on other cases. Clang doesn't diagnose at all. See below an example that is not diagnosed by GCC either:

	alx@devuan:~/tmp$ cat restrict2.c 
	int *f(int *restrict a, int **restrict b);

	int
	main(void)
	{
		int *x = &(int){0};

		f(x, &x);
	}

	int *
	f(int *restrict a, int **restrict b)
	{
		*a = 42;
		*b = a;
		return *b;
	}
	alx@devuan:~/tmp$ gcc -Wall -Wextra restrict2.c 
	alx@devuan:~/tmp$ clang -Weverything restrict2.c 
	alx@devuan:~/tmp$ 

This program is also fine according to ISO C. Neither GCC nor Clang emit any diagnostics; and they can't! If they diagnosed this, they'd have to diagnose on valid uses of strtol(3), and that would be unacceptable.

But if compilers can't diagnose on the call f(x,&x) where f()'s parameters are restrict, what stops one from passing aliasing pointers to a function that really accesses its parameters? The compiler can't know what the function will do with them. Thus, restrict results in having more UB, and the optimizations it enables can make that UB even more dangerous.

And unsurprisingly, the rationale for restrict was optimizations, not diagnostics. That's a bad idea.

restrict should eventually be replaced by an attribute (a qualifier won't work). Such an attribute should be defined only in terms of aliasing of pointers, and not on accesses. That would turn it into a tool for diagnostics instead of a tool for optimization (while it would still allow for optimizations in most cases), and that is a good idea.

Have a lovely day!
Alex

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

Hi Seth,

On Wed, Jan 21, 2026 at 06:12:45AM +0000, Seth McDonald wrote:
[...]

Yes.

Yes, a line saying that POSIX.1-1988 was heavily influenced by the development of C89 would be good, I think.

Cheers,
Alex

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

faccessat(2) first appeared in POSIX.1-2008.[1]

[1] IEEE Std 1003.1-2008, Volume 2, Chapter 3 "System Interfaces", pp. 561-563.
<https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/access.html>

---
 man/man2/access.2 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

index c0bcf016ae5c..ff198b25824a 100644
@@ -338,7 +338,8 @@ .SH HISTORY
 .TP
 .BR faccessat ()
 Linux 2.6.16,
-glibc 2.4.
+glibc 2.4,
+POSIX.1-2008.
 .TP
 .BR faccessat2 ()
 Linux 5.8.

2.47.3

alarm(2) first appeared in POSIX.1-1988.[1]

[1] IEEE Std 1003.1-1988, Section 3.4.1 "Schedule Alarm".

---
 man/man2/alarm.2 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

index 9edde18cdb48..6716b4d61c99 100644
@@ -37,7 +37,9 @@ .SH RETURN VALUE
 .SH STANDARDS
 POSIX.1-2024.
 .SH HISTORY
-POSIX.1-2001, SVr4, 4.3BSD.
+4.3BSD,
+SVr4,
+POSIX.1-1988.
 .SH NOTES
 .BR alarm ()
 and

2.47.3

---
 man/man2/chdir.2 | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

index 83702d2af3c4..d8d274d7114b 100644
@@ -103,7 +103,16 @@ .SH ERRORS
 .SH STANDARDS
 POSIX.1-2024.
 .SH HISTORY
-POSIX.1-2001, SVr4, 4.4BSD.
+.TP
+.BR chdir ()
+SVr4,
+4.4BSD,
+POSIX.1-2001.
+.TP
+.BR fchdir ()
+SVr4,
+4.4BSD,
+POSIX.1-2001.
 .SH NOTES
 The current working directory is the starting point for interpreting
 relative pathnames (those not starting with \[aq]/\[aq]).

2.47.3

chdir(2) first appeared in POSIX.1-1988.[1]

[1] IEEE Std 1003.1-1988, Section 5.2.1 "Change Current Working Directory".

---
 man/man2/chdir.2 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

index d8d274d7114b..be53f87454e4 100644
@@ -106,8 +106,8 @@ .SH HISTORY
 .TP
 .BR chdir ()
 SVr4,
-4.4BSD,
-POSIX.1-2001.
+POSIX.1-1988,
+4.4BSD.
 .TP
 .BR fchdir ()
 SVr4,

2.47.3

chdir(2) was specified in POSIX.1-1988 with the prototype int chdir(char *path); [1]

POSIX.1-1990 then changed the prototype to
int chdir(const char *path); [2]

[1] IEEE Std 1003.1-1988, Section 5.2.1 "Change Current Working Directory".
[2] IEEE Std 1003.1-1990, Section 5.2.1 "Change Current Working Directory".

---
 man/man2/chdir.2 | 7 +++++++
 1 file changed, 7 insertions(+)

index be53f87454e4..a313071d2e1e 100644
@@ -113,6 +113,13 @@ .SH HISTORY
 SVr4,
 4.4BSD,
 POSIX.1-2001.
+.P
+POSIX.1-1988 initially specified the function signature of
+.BR chdir ()
+with a non-const-qualified
+.I path
+parameter.
+This was remedied in POSIX.1-1990.
 .SH NOTES
 The current working directory is the starting point for interpreting
 relative pathnames (those not starting with \[aq]/\[aq]).

2.47.3

fchdir(2) first appeared in SUSv1.[1] The function was added to POSIX.1-2001 when POSIX and SUS merged, but as an XSI extension (still SUS-only).[2] Then POSIX.1-2008 added it to the base specification.[3]

[1] X/Open CAE Specification, System Interfaces and Headers Issue 4, Version 2, Chapter 3 "System Interfaces", p. 143.
[2] IEEE Std 1003.1-2001, Volume 2, Chapter 3 "System Interfaces", p. 320.
<https://pubs.opengroup.org/onlinepubs/009604499/functions/fchdir.html>
[3] IEEE Std 1003.1-2008, Volume 2, Chapter 3 "System Interfaces", p. 798.
<https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/fchdir.html>

---
 man/man2/chdir.2 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

index a313071d2e1e..24f4d44d90f4 100644
@@ -112,7 +112,9 @@ .SH HISTORY
 .BR fchdir ()
 SVr4,
 4.4BSD,
-POSIX.1-2001.
+SUSv1,
+POSIX.1-2001 XSI,
+POSIX.1-2008.
 .P
 POSIX.1-1988 initially specified the function signature of
 .BR chdir ()

2.47.3

---
 man/man2/chmod.2 | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

index 20cf8649d4cc..998869dc8097 100644
@@ -344,9 +344,14 @@ .SH STANDARDS
 .SH HISTORY
 .TP
 .BR chmod ()
-.TQ
+SVr4,
+4.4BSD,
+POSIX.1-2001.
+.TP
 .BR fchmod ()
-4.4BSD, SVr4, POSIX.1-2001.
+SVr4,
+4.4BSD,
+POSIX.1-2001.
 .TP
 .BR fchmodat ()
 POSIX.1-2008.

2.47.3

chmod(2) first appeared in POSIX.1-1988.[1]

[1] IEEE Std 1003.1-1988, Section 5.6.4 "Change File Modes".

---
 man/man2/chmod.2 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

index 998869dc8097..d9e316747f98 100644
@@ -345,8 +345,8 @@ .SH HISTORY
 .TP
 .BR chmod ()
 SVr4,
-4.4BSD,
-POSIX.1-2001.
+POSIX.1-1988,
+4.4BSD.
 .TP
 .BR fchmod ()
 SVr4,

2.47.3

chmod(2) was specified in POSIX.1-1988 with the prototype int chmod(char *path, mode_t mode); [1]

POSIX.1-1990 then changed the prototype to
int chmod(const char *path, mode_t mode); [2]

[1] IEEE Std 1003.1-1988, Section 5.6.4 "Change File Modes".
[2] IEEE Std 1003.1-1990, Section 5.6.4 "Change File Modes".

---
 man/man2/chmod.2 | 7 +++++++
 1 file changed, 7 insertions(+)

index d9e316747f98..78bd4d05139f 100644
@@ -361,6 +361,13 @@ .SH HISTORY
 .B AT_SYMLINK_NOFOLLOW
 glibc 2.32,
 Linux 6.5.
+.P
+POSIX.1-1988 initially specified the function signature of
+.BR chmod ()
+with a non-const-qualified
+.I path
+parameter.
+This was remedied in POSIX.1-1990.
 .SH SEE ALSO
 .BR chmod (1),
 .BR chown (2),

2.47.3

fchmod(2) first appeared in SUSv1.[1] The function was then added to POSIX.1-1996.[2]

[1] X/Open CAE Specification, System Interfaces and Headers Issue 4, Version 2, Chapter 3 "System Interfaces", p. 144.
[2] ISO/IEC 9945-1:1996, Section 5.6.4 "Change File Modes".

---
 man/man2/chmod.2 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

index 78bd4d05139f..d47360909bb4 100644
@@ -351,7 +351,8 @@ .SH HISTORY
 .BR fchmod ()
 SVr4,
 4.4BSD,
-POSIX.1-2001.
+SUSv1,
+POSIX.1-1996.
 .TP
 .BR fchmodat ()
 POSIX.1-2008.

2.47.3

The AT_SYMLINK_NOFOLLOW symbolic constant first appeared in POSIX.1-2008.[1]

[1] IEEE Std 1003.1-2008, Volume 1, Chapter 13 "Headers", p. 239.
<https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/basedefs/fcntl.h.html>

---
 man/man2/chmod.2 | 1 +
 1 file changed, 1 insertion(+)

index d47360909bb4..20f640bf39a9 100644
@@ -360,6 +360,7 @@ .SH HISTORY
 glibc 2.4.
 .TP
 .B AT_SYMLINK_NOFOLLOW
+POSIX.1-2008,
 glibc 2.32,
 Linux 6.5.
 .P

2.47.3

---
 man/man2/chown.2 | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

index 4f741d251940..325f6a21a728 100644
@@ -279,11 +279,19 @@ .SH STANDARDS
 .SH HISTORY
 .TP
 .BR chown ()
-.TQ
+SVr4,
+4.4BSD,
+POSIX.1-2001.
+.TP
 .BR fchown ()
-.TQ
+SVr4,
+4.4BSD,
+POSIX.1-2001.
+.TP
 .BR lchown ()
-4.4BSD, SVr4, POSIX.1-2001.
+SVr4,
+4.4BSD,
+POSIX.1-2001.
 .TP
 .BR fchownat ()
 POSIX.1-2008.

2.47.3

chown(2) first appeared in POSIX.1-1988.[1]

[1] IEEE Std 1003.1-1988, Section 5.6.5 "Change Owner and Group of a File".

---
 man/man2/chown.2 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

index 325f6a21a728..f6577aa9489f 100644
@@ -280,8 +280,8 @@ .SH HISTORY
 .TP
 .BR chown ()
 SVr4,
-4.4BSD,
-POSIX.1-2001.
+POSIX.1-1988,
+4.4BSD.
 .TP
 .BR fchown ()
 SVr4,

2.47.3

chown(2) was specified in POSIX.1-1988 with the prototype int chown(char *path, uid_t owner, gid_t group); [1]

POSIX.1-1990 then changed the prototype to
int chown(const char *path, uid_t owner, gid_t group); [2]

[1] IEEE Std 1003.1-1988, Section 5.6.5 "Change Owner and Group of a File".
[2] IEEE Std 1003.1-1990, Section 5.6.5 "Change Owner and Group of a File".

---
 man/man2/chown.2 | 7 +++++++
 1 file changed, 7 insertions(+)

index f6577aa9489f..ec1cfe33d234 100644
@@ -297,6 +297,13 @@ .SH HISTORY
 POSIX.1-2008.
 Linux 2.6.16,
 glibc 2.4.
+.P
+POSIX.1-1988 initially specified the function signature of
+.BR chown ()
+with a non-const-qualified
+.I path
+parameter.
+This was remedied in POSIX.1-1990.
 .SH NOTES
 .SS Ownership of new files
 When a new file is created (by, for example,

2.47.3

fchown(2) first appeared in SUSv1.[1]

[1] X/Open CAE Specification, System Interfaces and Headers Issue 4, Version 2, Chapter 3 "System Interfaces", p. 145.

---
 man/man2/chown.2 | 1 +
 1 file changed, 1 insertion(+)

index ec1cfe33d234..0e0c6f170fb7 100644
@@ -286,6 +286,7 @@ .SH HISTORY
 .BR fchown ()
 SVr4,
 4.4BSD,
+SUSv1,
 POSIX.1-2001.
 .TP
 .BR lchown ()

2.47.3

lchown(2) first appeared in SUSv1.[1] The function was added to POSIX.1-2001 when POSIX and SUS merged, but as an XSI extension (still SUS-only).[2] Then POSIX.1-2008 added it to the base specification.[3]

[1] X/Open CAE Specification, System Interfaces and Headers Issue 4, Version 2, Chapter 3 "System Interfaces", p. 349.
[2] IEEE Std 1003.1-2001, Volume 2, Chapter 3 "System Interfaces", p. 671.
<https://pubs.opengroup.org/onlinepubs/009604499/functions/lchown.html>
[3] IEEE Std 1003.1-2008, Volume 2, Chapter 3 "System Interfaces", pp. 1206-1208.
<https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/lchown.html>

---
 man/man2/chown.2 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

index 0e0c6f170fb7..55de93efae72 100644
@@ -292,7 +292,9 @@ .SH HISTORY
 .BR lchown ()
 SVr4,
 4.4BSD,
-POSIX.1-2001.
+SUSv1,
+POSIX.1-2001 XSI,
+POSIX.1-2008.
 .TP
 .BR fchownat ()
 POSIX.1-2008.

2.47.3

chroot(2) first appeared in SUSv1 with the 'TO BE WITHDRAWN' marking.[1] It was given this marking because "[t]here is no portable use that an application could make of this interface."

[1] X/Open CAE Specification, System Interfaces and Headers Issue 4, Version 2, Chapter 3 "System Interfaces", pp. 88-89.

---
 man/man2/chroot.2 | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

index 090a88f0c397..bcb8da39a231 100644
@@ -135,7 +135,10 @@ .SH ERRORS
 .SH STANDARDS
 None.
 .SH HISTORY
-SVr4, 4.4BSD, SUSv2 (marked LEGACY).
+SVr4,
+4.4BSD,
+SUSv1 (marked TO BE WITHDRAWN),
+SUSv2 (marked LEGACY).
 This function is not part of POSIX.1-2001.
 .\" SVr4 documents additional EINTR, ENOLINK and EMULTIHOP error conditions.
 .\" X/OPEN does not document EIO, ENOMEM or EFAULT error conditions.

2.47.3

Hi Seth,

Thanks! I've applied most patches. The ones that document non-const old prototypes, I've not applied those; all others have been applied.

Yup; that worked! All patches were correctly signed, and none were corrupted (or at least I didn't notice). Out of curiosity, what was the workaround? And how did you sign the patches? Was it with neomutt(1)?

Have a lovely night!
Alex

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