Re: History of const in C++, C89, and POSIX.1-1988 (was: [PATCH v1 02/19] man/man2/access.2: HISTORY: Specify different)

[Seth McDonald <sethmcmail@pm.me>]

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

Hi Alex,

On Tue, Jan 20, 2026 at 02:52:22PM +0100, Alejandro Colomar wrote:
> Hi Seth,
> 
> On Tue, Jan 20, 2026 at 12:13:32PM +0000, Seth McDonald wrote:
[...]
> > 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).
> 
> 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'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.

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

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


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