Re: [PATCH v1 02/19] man/man2/access.2: HISTORY: Specify different access(2) prototypes

[Seth McDonald <sethmcmail@pm.me>]

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

On Tue, Jan 20, 2026 at 02:34:08AM +0100, Alejandro Colomar wrote:
> Hi Seth,
> 
> On Mon, Jan 19, 2026 at 11:55:06AM +0000, Seth McDonald wrote:
> > 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]
> 
> 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.

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

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 322 bytes --]