Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar <alx@kernel.org>]

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

> Date: 2026-08-02 00:22:37+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> Hi Branden,
> 
> > Date: 2026-08-01 16:34:21-0500
> > From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
> >
> > Hi Alex,
> > 
> > At 2026-08-01T19:09:36+0200, Alejandro Colomar wrote:
> > > Well, Keith Bostic wouldn't have suggested that I do this change, and
> > > Branden wouldn't be defending that it might make sense to make this
> > > change.
> > 
> > I'm flattered to be mentioned in the same breath as Keith Bostic!
> 
> :)
> 
> > > A vocal majority is not consensus.  Consensus would be if there were
> > > no significantly different or strongly opposed opinions to those of
> > > the majority.  Even my strong and sustained opposition against your
> > > opinion already means there's no consensus against.
> > 
> > "Consensus" is a word that gets abused a lot, because it has multiple
> > definitions.  To some people it means "unanimity".  To others, it means
> > a majority vote with potentially many abstentions but no (or
> > proportionally very few) negative votes.
> 
> Indeed.
> 
> > From reading WG14 minutes, I'm
> > vaguely aware that it has a rubric for reading the straw polls they take
> > when voting on N-papers and related motions.[1]  I invite a member to
> > cite a resource laying out their actual procedures.
> 
> WG14, like WG21, has a problem.  Consensus, these days, is taken as
> roughly a majority of votes.
> 
> With very few exceptions, here's the rule that guides consensus in straw
> polls during committee meetings:
> 
> 		// Consensus requires both
> 		//	y/(y+n)   >= 2/3
> 		//	n/(y+n+a) <= 1/4
> 
> Strong opposition is dismissed as long as the numbers are okay.  We even
> have a small program that performs that calculation and which we
> consult.
> 
> As a consequence, this is what happens (very interesting read):
> <https://isocpp.org/files/papers/P4238R0.pdf>.
> 
> A large number of NBs (national bodies), including mine, are going to
> vote against C++26, and as a consequence, it may be returned to WG21 for
> evaluation.  This means we won't have C++26 if this happens.
> 
> > I don't think I'm voicing a controversial view when I venture that
> > Michael Kerrisk administered the Linux man-pages with a more settled
> > view of the APIs it documents.  By that, I mean that he tended to update
> > its content with a retrospective view of matters that were no longer in
> > contention.  If some controversy brewed, he tended to omit it from
> > "coverage" in the documentary corpus until the contention resolved.
> 
> Yup.
> 
> > Your approach is a little different: you're more ready to give the
> > reader a view of live controversies and unsettled matters troubling the
> > C community where these intersect with the topics man-pages(7) covers.
> 
> Yup.
> 
> > Neither approach is better.  They're just different.
> 
> Yup.
> 
> > I think Sam is
> > right that people had many years to get used to Michael's approach.
> > From there it's a short--but logically unsound--step to associate
> > "familiar" with "better".
> 
> Yup.
> 
> > But, if you're going to document unresolved controversies, how do you
> > avoid putting a thumb on the scale?
> 
> Doing a lot of research.  Whatever I don't research myself, I still act
> like Michael, and tend to not step into.  But string and memory handling
> is something that has taken most of my time in the last 5 years or so.

In fact, I'd say I'm quite like Michael.  It's just that Michael was an
expert in other topics, more related to man2 and man7, and I'm more of
an expert in libc (man3).  Thus, Michael wrote quite a lot of somewhat-
opinionated paragraphs in man2 and man7, which for some reason didn't
trigger this amount of criticism (maybe because he added the text while
the pages were added, and thus it didn't come as revisionism).


Cheers,
Alex

> > One way is to solicit review of that coverage for even-handedness--I
> > do not say "neutrality".  List pros and cons of competing interfaces or
> > code idioms.
> 
> I do indeed get that.  Mark gave me feedback about memccpy(3) recently,
> which I've incorporated to my research.  That was the last issue I had
> with <string.h>, because memccpy(3) is something I've never seen in real
> correct use.  It seems Illumos is one of the places where they store
> that old knowledge.  It's good that those projects still exist and can
> be used to learn about our history.
> 
> Sam was concerned about not docuementing what standards say; and indeed,
> I'll make sure to document that (in STANDARDS, where it belongs; which
> I had already done, BTW).  Other than that, he was worried that I might
> be encoding an opinion, but I believe this is a technical judgement
> based on research, and not an opinion.  So, dismissed.
> 
> Joseph was concerned that this documentation would conflict with many
> documents saying that <memory.h> is deprecated.  Luckily, I've never
> seen such a document, so we can assume they don't exist (unless people
> show evidence).  I'll dismiss his negative vote, since his technical
> reasons are incorrect.  Also, <memory.h> is undoubtedly more portable 
> than a new <stdmem.h>.
> 
> It's also a bit Ironic that Joseph started with a strongly opinionated
> proposal: deprecating <memory.h> in glibc (breaking 8.9k uses in
> Debian).
> 
> Collin didn't comment, although by his support to Joseph's suggestion
> of deprecating <memory.h>, I guess he's against.  Since he didn't
> provide any new reasons, I guess it's more of Joseph's.  Already
> dismissed, then.
> 
> Nevin has an undeclared conflict of interest:  He is the author of a
> proposal for WG14 to remove strncpy(3).
> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3935.htm>
> Also, he didn't really give any technical reasons; he just voted no.
> A vote without reasons is still heard, but easily dismissed.
> 
> Keith suggested doing this, by which I assume he's in favour.  He's
> certainly an expert in the topic, and I'd value his support.
> 
> I value Doug's opinion too, although he didn't show much technical
> reasons this time.  He was mostly concerned about changing string
> functions, but didn't clarify whether he was concerned about restoring
> <memory.h>.  Thus, I'd say I won't count that.
> 
> You seem to support the fact that something should be done, except that
> you may not entirely agree with the approach.  You've been a bit
> misguided by Joseph's concerns about <memory.h>, so I'll dismiss that
> part of your feedback as being just Joseph's --which I've already
> dismissed on technical grounds--.
> 
> Chris is concerned about my arbitrary separation, but I think his
> separation is also somewhat arbitrary.  I'll trust my instinct here.
> We're always in time to revise this.  In any case, this arbitrary
> distinction is better than the status quo.
> 
> Thus, with support from Keith, and no sustained opposition based on
> technical ground (Joseph didn't contest my response that absolutely no
> mainstream documents talk about <memory.h> being deprecated, and himself
> said that it's only *implicitly* deprecated), I should commit.
> 
> >  If you do that job correctly, _reasonable_ partisans of
> > the various contesting positions will find no cause to criticize.
> > (There will sometimes be fanboys who object to the "opposition" getting
> > any coverage at all.)
> > 
> > Further, with such lists you do a service to the engineer who must
> > select a means of solving the problem confronting them.  The engineer
> > often knows that problem better than anyone else does.
> > 
> > Next comes a trickier bit: what if you yourself get involved, even while
> > "wearing a different hat", in one of these live controversies?
> > 
> > Your first line of defense is your own ethical conscience.
> > 
> > Another, as I suggested earlier, is to solicit one or more volunteers to
> > serve as "deputy maintainers".  Prepare a list of man pages or sections
> > thereof upon which you are "conflicted out", and ask the deputies to
> > field all Linux man-pages business regarding those pages/sections while
> > you have business regarding those interfaces before a vendor libc and/or
> > the WG14 committee.  It will likely be obvious to you what vehicle can
> > communicate these areas of deputy maintenance--a man page!
> > 
> > I intuit that Michael had a hard time finding anyone to take the mantle
> > of Linux man-pages maintainership.  It's a huge job and demanded someone
> > of your unusual resources and energy.  By opening deputy positions that
> > are limited both in scope and in time, nobody need worry that they'll be
> > expected to eat the whole elephant.  If you find such volunteers, then
> > you'll also be spreading expertise and socializing personal investment
> > in the success of this project.  That's good management!
> 
> I have a mental list of people to whom I consult when I don't think
> I should make the decision alone.  The list isn't fixed, and varies
> wildly depending on the topics, but you can get an idea when I CC people
> in discussions.  You've been yourself quite some times.  :)
> 
> > Finally, to return to the question of consensus: a potential point of
> > development in Linux man-pages project governance is to _document how
> > you measure consensus_.
> 
> Nope.  I'll quote <https://isocpp.org/files/papers/P4238R0.pdf>:
> 
> 	2. How Consensus Is Supposed to Work
> 	WG21 decides by consensus, not by vote.  The chair, a
> 	subject-matter expert, weighs the arguments of every side.
> 	Where they can be reconciled, the chair reconciles them.  Where
> 	they cannot be reconciled, the chair decides, and may decide
> 	against the numerical majority.  This is deliberate: WG21's own
> 	guidance states that "the chair's determination of consensus is
> 	authoritative, not the straw poll" and that "we make decisions
> 	by consensus, not majority" (P2195R2), and ISO defines consensus
> 	as a process that takes all views into account and reconciles
> 	conflicting arguments, not a count of hands (ISO/IEC Directives
> 	Part 1, clause 2.5.6).  The chair's authority is broad by
> 	design, and rightly so; a committee that decided technical
> 	questions by votes rather than expert judgment would be worse.
> 
> That is, I use my judgement as an expert.  That's all we can document.
> 
> > We'd be unwise to determine consensus by measuring who writes the most
> > words (hi, folks), or with the angriest tone, or who has the most
> > impressive job title at the biggest company, or who can shut down a
> > discussion most coldly or derail it most effectively.
> > 
> > So tell the members of this community how _you_ measure it.  Put the
> > burden on the critical and the concerned to find flaws in your method.
> 
> At least, I've documented how and why I've valued the feedback from each
> one this (so-contentious) time.
> 
> If anyone wants to appeal, I'll be open to changing my mind based on new
> technical reasons.
> 
> 
> Cheers,
> Alex
> 
> > Regards,
> > Branden
> > 
> > [1]  I'm not sure WG14 uses the term "motions", and I haven't seen much
> >      evidence that they use Robert's Rules of Order, with which
> >      Commonwealth people are likely not familiar, let alone
> >      non-Anglophones.
> 
> 
> 
> -- 
> <https://www.alejandro-colomar.es>



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

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