Re: on the irresponsibility of pursuing C language reform

["G. Branden Robinson" <g.branden.robinson@gmail.com>]

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

Hi Sam,

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.

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.

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.

> (*) 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.

Regards,
Branden

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