Linux Manual Pages development
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: Joseph Myers <josmyers@redhat.com>,
	 Alejandro Colomar <alx@kernel.org>,
	linux-man@vger.kernel.org,  Keith Bostic <keith@bostic.com>,
	 Mark Harris <mark.hsj@gmail.com>,
	 Nevin Liber <nevin@cplusplusguy.com>,
	 JeanHeyd Meneide <phdofthehouse@gmail.com>,
	 Christopher Bazley <chris.bazley.wg14@gmail.com>,
	 "Serge E. Hallyn" <serge@hallyn.com>,
	Iker Pedrosa <ipedrosa@redhat.com>,
	 "Evgeny Grin (Karlson2k)" <k2k@drgrin.dev>,
	 Kees Cook <keescook@chromium.org>,
	 bug-gnulib@gnu.org, libc-alpha@sourceware.org
Subject: Re: on the irresponsibility of pursuing C language reform
Date: Sat, 01 Aug 2026 15:52:13 +0100	[thread overview]
Message-ID: <87h5lddhb6.fsf@gentoo.org> (raw)
In-Reply-To: <20260731222417.4fo36is3iawyc7d4@illithid>

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

"G. Branden Robinson" <g.branden.robinson@gmail.com> writes:

> Hi Sam,

Hi Branden,

>
> At 2026-07-31T22:59:47+0100, Sam James wrote:
>> "G. Branden Robinson" <g.branden.robinson@gmail.com> writes:
>> > At 2026-07-31T21:23:35+0000, Joseph Myers wrote:
>> >> I think it's irresponsible to use the man-pages project to promote
>> >> personal idiosyncratic ideas like this in preference to what's been
>> >> the standard location of functions since 1989.
>> >
>> > I'm sure I don't need to bring to your attention what a mine field
>> > string/`char` sequence/memory buffer handling has been in C since the
>> > language's inception.
>> >
>> > More to the point: what's a better forum for pursuing this attempt at
>> > reform that will both (a) reach a significant population of stakeholders
>> > who can variously red-team it and/or endorse it; and (b) has sufficient
>> > visibility that it can't easily be ignored by people who oppose reform
>> > in this area for whatever reason?
>> 
>> I think the man page already tries to discourage use in its CAVEATS
>> section.
>
> Yes, but that's not a language reform, which is what Alex is pursuing
> with "alx-0097r1".  In at least one earlier iteration he's expressed his
> intention to submit an N document to WG14.
>
>> > I hope you do not wish to imply that a closed session of some
>> > committee, or unofficial backroom politicking would be preferable,
>> > nor that WG14 should close its doors to members of its user
>> > community who have not been vetted for a disinclination to
>> > boat-rocking.
>> 
>> I am confused as to where that implication could have possibly come
>> from.
>
> From familiarity with Alex's stated objective and rationale, which we
> can acquire from the recent list traffic Joseph characterized as
> irresponsible.

Ah, I see. Thanks for explaining.

To clarify then: I have no issue with Alex advocating changes. I just
have an issue with man-pages being used regularly as a vehicle for that.

>
> AC> The C Committee is discussing standardization of <memory.h>, so
> AC> let's give it a bump.
>
> AC> I'll send you a copy of a paper I'm writing for the C Committee.
>
> AC> It is at the bottom of this email.  I will publish it as an N
> AC> document in August.
>
> https://lore.kernel.org/linux-man/784288e704183a4297aeaa3d13af8edab18bc1ea.1785532392.git.alx@kernel.org/
> https://lore.kernel.org/linux-man/amaTpQxd52iYjlor@devuan/
>
>> Joseph is opposing the change in the form of a patch that is
>> likely to be applied (*) to man-pages.git which has the effect of
>> advocacy.
>
> Yes, and he said so categorically.  More constructive advice might have
> taken the form of recommending a sequencing for staged changes.  Here's
> a crude sketch.
>

I agree this is more productive, thanks for setting it out.

> 1.  Expand "CAVEATS" sections in relevant Linux man-pages documents.
> 2.  Pursue N-document work with WG14.
> 3.  When WG14 has disposed of that N-document (and any descendants
>     thereof), update Linux man-pages documents as appropriate.
>
> Joseph's almost certainly better placed than I to add a "step 1.5"
> such that Alex might pursue some course that would better prepare the
> ground for his step 2.  I haven't attempted revision of the C language
> standard myself, so I can't offer specific advice regarding how best to
> pursue such an objective.  I possess only notions of elemental
> principles regarding how democratic, consultative bodies of technical
> experts _should_ serve the public.
>
> That _is_ what we're here for, right?
>
>> I don't think it has anything to do with WG14 membership or anything
>> of the like? What am I missing?
>
> See above regarding Alex's publicly circulated drafts and expressed
> plans.

What I mean is that I didn't take Joseph's comments to be an objection
to Alex's WG14 membership or anything of the sort, just that man-pages
isn't an appropriate vehicle for it. In any case, that's my position
even if I misunderstood Joseph's.

>
>> (*) Alex has a history of making opinonated changes like this to
>>     man-pages, such as removing references to older standards, and
>>     using a somewhat novel (to many) syntax for prototypes.
>
> I concur with that assessment.  However, a person having a history of
> making opinionated changes is not sound grounds for evaluation of a
> technical proposal, especially if it's topically unrelated.
>
> Preoccupying oneself with irrelevancies distracts from the conscientious
> execution of standards committee participation.
>

Thanks for your thoughtful email. I found it helpful!

> Regards,
> Branden

sam

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

  parent reply	other threads:[~2026-08-01 14:52 UTC|newest]

Thread overview: 44+ 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 [this message]
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-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-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

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=87h5lddhb6.fsf@gentoo.org \
    --to=sam@gentoo.org \
    --cc=alx@kernel.org \
    --cc=bug-gnulib@gnu.org \
    --cc=chris.bazley.wg14@gmail.com \
    --cc=g.branden.robinson@gmail.com \
    --cc=ipedrosa@redhat.com \
    --cc=josmyers@redhat.com \
    --cc=k2k@drgrin.dev \
    --cc=keescook@chromium.org \
    --cc=keith@bostic.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mark.hsj@gmail.com \
    --cc=nevin@cplusplusguy.com \
    --cc=phdofthehouse@gmail.com \
    --cc=serge@hallyn.com \
    /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