public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Seth McDonald <sethmcmail@pm.me>
Cc: linux-man@vger.kernel.org
Subject: Re: [PATCH v1 19/25] man/man3type/void.3type: HISTORY: Update first POSIX appearance of void(3type)
Date: Sat, 10 Jan 2026 12:30:13 +0100	[thread overview]
Message-ID: <aWI0djUqajn0xGZL@devuan> (raw)
In-Reply-To: <N5rwikkzw2f0JXz95u_1kI4bAmDj9D2gkp_MrOGQRmYRpZUHBuRAP390fgTkgcNbzYe3YAfS3Zb-OT95Mc_XjSCLQwr-JnMM6fLmIlsN8NI=@pm.me>

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

Hi Seth,

On Sat, Jan 10, 2026 at 07:57:49AM +0000, Seth McDonald wrote:
> Hi Alex,
> 
> On Friday, 9 January 2026 at 20:34, Alejandro Colomar <alx@kernel.org> wrote:
> > Hi Seth,
> [...]
> > I think 'void*' is important enough that it would be useful to dig in
> > its history further. Was it an invention of C89? Or was it an
> > extension in some existing compilers? If the latter, it would be
> > interesting to document which systems had it before C89.
> >
> > I'm mentioning this just in case you know. Feel free to ignore
> > otherwise.
> 
> I know that the void pointer type was not mentioned or used in
> POSIX.1-1988.  Instead, the standard used the char pointer type for
> pointers to generic data.  POSIX.1-1990 seems to implicitly require void
> pointers - at least for conformance to "POSIX.1, C Language Binding (C
> Standard Language-Dependent System Support)" - by including them in some
> function prototypes.

Hmmm, since POSIX.1-1988 was already written after some C89 draft, it
seems void* was incorporated to C89 in a late draft.

> 
> Looking at C89, it did explicitly specify void pointers as part of the
> language, stating that "[a] pointer to void shall have the same
> representation and alignment requirements as a pointer to a character
> type."[1]
> 
> Looking* at K&R C, I skimmed through chapter 5 "Pointers and Arrays",
> and couldn't find any references to void pointers.  In fact, it seems to
> use char pointers instead, similar to POSIX.1-1988.

Yup, K&R C 1st ed. is too old and I wouldn't expect it to have
void*.  I have a physical copy of K&R C 2nd ed. (1988) and it does have
void*.

> So I think what happened (pure speculation) was between 1978 and 1989,
> void pointers increased in user popularity and compiler support enough
> that ANSI decided to extend the language by adding void pointers to its
> 1989 C standard.  Which would explain why POSIX.1-1988 also didn't have
> void pointers, but POSIX.1-1990 suddenly did.
> 
> With regard to implementation support for void pointers prior to C89,
> this is where my knowledge falls short.  I'm not the most educated on
> past implementations (yet).

That's fine.  If anyone else reading the list knows anything, it would
be welcome.

> *I found this[2] PDF online which appears to be a scan of a (heavily
> annotated) copy of the first edition of The C Programming Language.
> I don't know if it's authentic though, so take it with a grain of salt.

Being a scan, it could be authentic.  I don't have a physical copy of
the first edition, so can't compare.

Be careful of online copies of K&R C, though.  I once found one of the
second edition, and it was fake (by comparing it to the actual copy).

Much better to get the physical copy.  Although the first edition seems
difficult to find.


Cheers,
Alex

> ----
> [1] ANSI X3.159-1989 "Programming Language – C", Section 3.1.2.5
> "Types", p. 24.
> <https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub160.pdf>
> [2] Kernighan, Brian W., Ritchie, Dennis M. (1978). The C Programming
> Language (1st ed.).
> <https://retrofun.pl/wp-content/uploads/sites/2/2023/12/1978-ritchie-the-c-programming-language.pdf>
> 
> ----
> Seth McDonald.
> sethmcmail at pm dot me (mailing lists)
> 2336 E8D2 FEB1 5300 692C  62A9 5839 6AD8 9243 D369




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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-01-10 11:30 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-09  6:40 [PATCH v1 00/25] man/man3type/*: Update history of all other types Seth McDonald
2026-01-09  6:40 ` [PATCH v1 01/25] man/man3type/div_t.3type: HISTORY: Update first SUS appearance of [l]div_t(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 02/25] man/man3type/id_t.3type: HISTORY: Update first POSIX appearance of id_t(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 03/25] man/man3type/intptr_t.3type: HISTORY: Split types and macros Seth McDonald
2026-01-09  6:40 ` [PATCH v1 04/25] man/man3type/intptr_t.3type: HISTORY: Update first POSIX appearance of [u]intptr_t(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 05/25] man/man3type/intptr_t.3type: HISTORY: Update first POSIX appearance of [U]INTPTR_MAX and INTPTR_MIN Seth McDonald
2026-01-09  6:40 ` [PATCH v1 06/25] man/man3type/intptr_t.3type: HISTORY: [U]INTPTR_WIDTH is not in POSIX Seth McDonald
2026-01-09  6:40 ` [PATCH v1 07/25] man/man3type/intptr_t.3type: DESCRIPTION: ffix Seth McDonald
2026-01-09  6:40 ` [PATCH v1 08/25] man/man3type/iovec.3type: HISTORY: Update first POSIX appearance of iovec(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 09/25] man/man3type/lconv.3type: HISTORY: Split lconv(3type) and int_[np]_{cs_precedes,sep_by_space,sign_posn} Seth McDonald
2026-01-09  6:40 ` [PATCH v1 10/25] man/man3type/lconv.3type: HISTORY: Update first SUS appearance of lconv(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 11/25] man/man3type/mbstate_t.3type: HISTORY: Update first SUS appearance of mbstate_t(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 12/25] man/man3type/ptrdiff_t.3type: HISTORY: Update first SUS appearance of ptrdiff_t(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 13/25] man/man3type/size_t.3type: HISTORY: Update first POSIX appearance of [s]size_t(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 14/25] man/man3type/time_t.3type: HISTORY: Update first POSIX appearance of time_t(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 15/25] man/man3type/time_t.3type: HISTORY: Update first POSIX appearance of suseconds_t(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 16/25] man/man3type/time_t.3type: HISTORY: Update first POSIX appearance of useconds_t(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 17/25] man/man3type/timeval.3type: HISTORY: Update first SUS appearance of timeval(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 18/25] man/man3type/va_list.3type: HISTORY: Update first SUS appearance of va_list(3type) Seth McDonald
2026-01-09  6:40 ` [PATCH v1 19/25] man/man3type/void.3type: HISTORY: Update first POSIX appearance of void(3type) Seth McDonald
2026-01-09 10:33   ` Alejandro Colomar
2026-01-10  7:57     ` Seth McDonald
2026-01-10 11:30       ` Alejandro Colomar [this message]
2026-01-10 11:52         ` origin of "void *" (was: " G. Branden Robinson
2026-01-10 12:07           ` Alejandro Colomar
2026-01-10 12:07             ` Alejandro Colomar
2026-01-10 22:32     ` Adam Sampson
2026-01-12 14:28       ` Alejandro Colomar
2026-01-09  6:40 ` [PATCH v1 20/25] man/man3type/wchar_t.3type: HISTORY: Split wchar_t(3type) and WCHAR_M{AX,IN} Seth McDonald
2026-01-09  6:40 ` [PATCH v1 21/25] man/man3type/wchar_t.3type: HISTORY: Update first SUS appearance of wchar_t(3type) Seth McDonald
2026-01-09 10:37   ` Alejandro Colomar
2026-01-10  9:08     ` Seth McDonald
2026-01-10 11:44       ` Alejandro Colomar
2026-01-09  6:40 ` [PATCH v1 22/25] man/man3type/wchar_t.3type: HISTORY: Update first SUS appearance of WCHAR_M{AX,IN} Seth McDonald
2026-01-09  6:40 ` [PATCH v1 23/25] man/man3type/wint_t.3type: HISTORY: Split wint_t(3type) and WEOF from WINT_M{AX,IN} Seth McDonald
2026-01-09  6:40 ` [PATCH v1 24/25] man/man3type/wint_t.3type: HISTORY: Update first SUS appearance of wint_t(3type) and WEOF Seth McDonald
2026-01-09  6:40 ` [PATCH v1 25/25] man/man3type/wint_t.3type: DESCRIPTION: ffix Seth McDonald
2026-01-09 10:39 ` [PATCH v1 00/25] man/man3type/*: Update history of all other types Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aWI0djUqajn0xGZL@devuan \
    --to=alx@kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=sethmcmail@pm.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox