From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: Alejandro Colomar <alx@kernel.org>
Cc: Paul Eggert <eggert@cs.ucla.edu>,
linux-man@vger.kernel.org, bug-gnulib@gnu.org,
libc-alpha@sourceware.org
Subject: the Linux man-pages as an educational tool (was: [PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h>)
Date: Sat, 1 Aug 2026 19:08:33 -0500 [thread overview]
Message-ID: <20260802000833.zpu27l7ibvrbouna@illithid> (raw)
In-Reply-To: <am6CnOddgaM10pry@devuan>
[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]
At 2026-08-02T01:36:28+0200, Alejandro Colomar wrote:
> > Date: 2026-08-01 18:29:13-0500
> > From: Paul Eggert <eggert@cs.ucla.edu>
> >
> > On 8/1/26 17:10, Alejandro Colomar wrote:
> > > #include's aren't that important.
> >
> > But this whole thread is about #includes, no?
> >
> > I would focus energy on areas of the manual where effort provides
> > the most bang for the buck. As your remark suggests, this particular
> > area is low priority.
>
> I wouldn't call it low priority or low bang for the buck. What I mean
> is that it's not a breaking change.
>
> I believe education is important, and provides bang for the buck.
> It's not all about features. The features are already there, but
> misused.
I'd like to underscore this point. As I noted in my response to Doug,
the flagship book on C, as we all know, is stuck in 1988. The throne is
vacant, with many pretenders, some with excellent cases for service as
regent.
But no head wears the crown.
And at the same time many C programmers are shy of consulting the formal
standard. We can lament their lack of wisdom in doing so and in failing
to spin themselves up in standardese sufficiently to grapple with it.
But we can also throw 'em a bone. To where shall they turn?
Sure, if they're in Emacs, they might go to glibc's Info manual.
But some people dislike Info, and some people use a different libc.
So what remains for the motley crew left behind?
The man pages.
I think people come to the Linux man-pages in part to learn C. When I
was starting out, long ago, I wondered why there wasn't a man page for
the language itself. Years later, I learned that there once sort of had
been, in the 1970s. It was Ritchie's "C Reference Manual".[1]
But it wasn't on any Unix machine I had access to.
Why not?
Because Prentice-Hall didn't want it there. And still don't, I guess.
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/cman
Maybe education is not a job the Linux man-pages project _should_ have,
but it is one that has been thrust upon it.
Regards,
Branden
[1] Not a man page, but you could render it intelligibly with nroff.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-08-02 0:08 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 21:18 [PATCH 0/2] alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al Alejandro Colomar
2026-07-31 21:18 ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> Alejandro Colomar
2026-07-31 21:23 ` Joseph Myers
2026-07-31 21:28 ` Alejandro Colomar
2026-07-31 21:54 ` Sam James
2026-07-31 22:18 ` Alejandro Colomar
2026-08-01 0:12 ` Alejandro Colomar
2026-08-01 14:43 ` Sam James
2026-07-31 21:51 ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) G. Branden Robinson
2026-07-31 21:59 ` on the irresponsibility of pursuing C language reform Sam James
2026-07-31 22:24 ` G. Branden Robinson
2026-07-31 23:19 ` Alejandro Colomar
2026-08-01 14:52 ` Sam James
2026-08-01 12:01 ` Alejandro Colomar
2026-08-01 12:04 ` Alejandro Colomar
2026-08-01 14:38 ` Sam James
2026-08-01 15:15 ` Alejandro Colomar
2026-08-01 16:10 ` Sam James
2026-08-01 17:09 ` Alejandro Colomar
2026-08-01 21:34 ` G. Branden Robinson
2026-08-01 22:22 ` Alejandro Colomar
2026-08-01 22:26 ` Alejandro Colomar
[not found] ` <CAETFuj2OwoyK9J85r2f0RoXbHbXKA4gQJ=JZ-7=QoqGcMwk0+Q@mail.gmail.com>
2026-08-01 22:44 ` Alejandro Colomar
2026-08-01 23:24 ` Alejandro Colomar
2026-08-01 23:53 ` proposed revision to memory.h(3head) (was: on the irresponsibility of pursuing C language reform) G. Branden Robinson
2026-08-02 0:27 ` Alejandro Colomar
2026-08-02 1:03 ` Alejandro Colomar
2026-08-01 20:18 ` on the irresponsibility of pursuing C language reform G. Branden Robinson
2026-08-01 20:42 ` Alejandro Colomar
2026-08-01 20:45 ` Alejandro Colomar
2026-08-01 20:52 ` G. Branden Robinson
2026-08-01 21:12 ` Alejandro Colomar
2026-07-31 22:10 ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) Joseph Myers
2026-07-31 22:21 ` Alejandro Colomar
2026-07-31 22:28 ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> G. Branden Robinson
2026-07-31 22:42 ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) Joseph Myers
2026-07-31 22:52 ` Alejandro Colomar
2026-07-31 23:11 ` Joseph Myers
2026-07-31 23:32 ` G. Branden Robinson
2026-08-01 12:39 ` Alejandro Colomar
2026-08-01 14:26 ` Christopher Bazley
2026-08-01 15:29 ` Alejandro Colomar
2026-07-31 23:45 ` on the irresponsibility of pursuing C language reform (was: " Alejandro Colomar
2026-08-01 12:39 ` Douglas McIlroy
2026-08-01 19:54 ` G. Branden Robinson
2026-08-01 20:35 ` Alejandro Colomar
2026-07-31 23:08 ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> G. Branden Robinson
2026-07-31 23:28 ` Joseph Myers
2026-07-31 23:57 ` G. Branden Robinson
2026-08-01 0:06 ` Alejandro Colomar
2026-07-31 22:05 ` Alejandro Colomar
2026-07-31 22:16 ` Joseph Myers
2026-07-31 22:33 ` Alejandro Colomar
2026-07-31 23:48 ` [PATCH 1/2] man/man3/{mem, strn}*(): " Collin Funk
2026-07-31 23:52 ` Alejandro Colomar
2026-08-01 0:01 ` Alejandro Colomar
2026-07-31 21:19 ` [PATCH 2/2] man/man*/{string.3,memory.h.3head}: Move functions to a new page memory.h(3head) Alejandro Colomar
2026-07-31 21:20 ` [PATCH 0/2] alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al Alejandro Colomar
2026-08-01 0:25 ` [PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h> Alejandro Colomar
2026-08-01 22:22 ` Bruno Haible
2026-08-01 22:38 ` Alejandro Colomar
2026-08-01 22:55 ` Bruno Haible
2026-08-01 23:10 ` Alejandro Colomar
2026-08-01 23:26 ` Collin Funk
2026-08-01 23:34 ` Alejandro Colomar
2026-08-01 23:29 ` Paul Eggert
2026-08-01 23:36 ` Alejandro Colomar
2026-08-02 0:08 ` G. Branden Robinson [this message]
2026-08-02 0:45 ` the Linux man-pages as an educational tool (was: [PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h>) Alejandro Colomar
2026-08-02 1:04 ` the Linux man-pages as an educational tool Collin Funk
2026-08-02 1:15 ` G. Branden Robinson
2026-08-02 1:15 ` Alejandro Colomar
2026-08-02 1:49 ` Collin Funk
2026-08-02 11:29 ` Alejandro Colomar
2026-08-02 11:47 ` 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=20260802000833.zpu27l7ibvrbouna@illithid \
--to=g.branden.robinson@gmail.com \
--cc=alx@kernel.org \
--cc=bug-gnulib@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=libc-alpha@sourceware.org \
--cc=linux-man@vger.kernel.org \
/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