From: Alejandro Colomar <alx@kernel.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: Paul Eggert <eggert@cs.ucla.edu>,
linux-man@vger.kernel.org, bug-gnulib@gnu.org,
libc-alpha@sourceware.org
Subject: Re: 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: Sun, 2 Aug 2026 02:45:01 +0200 [thread overview]
Message-ID: <am6PkypxYg-Fq4Iz@devuan> (raw)
In-Reply-To: <20260802000833.zpu27l7ibvrbouna@illithid>
[-- Attachment #1: Type: text/plain, Size: 4072 bytes --]
Hi Branden,
> Date: 2026-08-01 19:08:33-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> 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.
In fact, the throne might currently fall in the Linux man-pages project.
While not being a blood heir of the Unix standards, it has become a
de-facto standard.
After all, both POSIX and C89 in one way or the other derive from the
Unix and System V manual pages (you can see it in their structure and
formatting). Unix and System V were the largest systems of their age,
and GNU+Linux is currently in that position. It's natural that its
manual pages are the current de-facto standard (no, not the texinfo
docs).
> 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.
Michael was wise to document different libc's, including the BSDs, in
the manual pages, which is why they've become a standard. If he had
limited to just glibc and Linux, it might not have been the case.
> So what remains for the motley crew left behind?
>
> The man pages.
Indeed.
> 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]
Hmmm, indeed, I believe that is the place to have it. It doesn't make
much sense to document only part of the language in the pages but not
all of it. FWIW, I've been documenting attributes and operators in the
manual pages recently. We're closing the gap.
> 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
Hmmm. Is there any copy of that?
> Maybe education is not a job the Linux man-pages project _should_ have,
I don't see why. In fact, I believe it's its ultimate job.
If documentation for a car was an aseptic piece of text describing
it mechanically but not saying how to use it, it wouldn't be much good.
It doesn't need to teach you how to drive (that's for driving schools),
but it certainly must educate the driver about the limitations of the
car, such as "this vehicle can lift from the ground if you drive at
300 mph, don't reach this speed". Or "if you have a lateral hit, the
airbag won't protect you".
Same happens here.
Cheers,
Alex
> 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.
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-08-02 0:45 UTC|newest]
Thread overview: 76+ 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 ` 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>) G. Branden Robinson
2026-08-02 0:45 ` Alejandro Colomar [this message]
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
2026-08-02 12:04 ` 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=am6PkypxYg-Fq4Iz@devuan \
--to=alx@kernel.org \
--cc=bug-gnulib@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=g.branden.robinson@gmail.com \
--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