Re: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>

Alejandro Colomar <[email protected]> Sat, 1 Aug 2026 02:06:50 +0200
Newsgroups	gmane.linux.man,gmane.comp.lib.gnulib.bugs,gmane.comp.lib.glibc.alpha
Message-ID	<am04Lt2WQ2wNonuz@devuan>
Hi Branden,

> Date: 2026-07-31 18:57:47-0500
> From: "G. Branden Robinson" <[email protected]>
>
> Hi Joseph,
> 
> At 2026-07-31T23:28:19+0000, Joseph Myers wrote:
> > And I consider it an abuse of position to change man-pages to declare
> > to users in general of C libraries on GNU/Linux that your standards
> > proposal, at a very early stage (not even an N-document), is the One
> > True Way of using the functions.
> 
> I agree that there is a _potential_ moral hazard here.
> 
> > It would be more neutral to say in the man pages that "as of July
> > 2026, one member of WG14 has proposed moving these functions to
> > <memory.h> [reference]; this proposal has not yet been considered by
> > WG14".  (I doubt the utility to users of describing proposed changes
> > in man-pages at such an early stage, especially since the information
> > would be long obsolete by the time those revisions of the pages make
> > it into distributions, but it would at least more accurately reflect
> > reality, and be vaguely neutral as long as you do it for *everyone's*
> > open proposals, *including those you personally disagree with*, rather
> > than privileging your own.)
> 
> I endorse this perspective.  Another thing Alex could do is gate such
> readily-obsolescent stuff behind a *roff register so that it doesn't
> format (or, if one uses soelim(1), even populate the document sources),
> for _official releases_, but is still there for people pulling on Alex's
> Git repository.
> 
> My interpretation of Alex's tactics is that he feels energetic about his
> proposal, is willing to think it through carefully and advocate for
> it--these are good things--and that he wants to get it in front of
> domain experts and anneal it by fire before formally putting it before
> WG14--_also_ a good thing!  In the meantime, he is the steward of a
> platform that _is_ topically implicated.
> 
> Such a position _can_ be abused, but it also seems not quite fair to me
> to expect him to stifle his advocacy in a _relevant_ forum.
> 
> Conventionally, what Alex faces is a potential conflict of interest.
> There are a variety of ways to cope with those.  Foremost is disclosure
> to others of the potential conflict.  That's such an important factor
> that I'd say it's 90% of the battle.  Most of the time when people
> resist disclosing potential CofIs it's because they're self-dealing,
> they know it, and realize that disclosure would be self-incriminating.

Indeed.  While I haven't explicitly mentioned CofI, I haven't hidden it
either, and have mentioned all the relevant information.  If I haven't
merged this single-handedly, it's precisely because I think there could
be some, and want to get feedback.


Cheers,
Alex

> 
> There is another tier to the issue, and its recourse is recusal.  We
> most often see this in the context of arbitration or in the judiciary.
> 
> However, Alex is not situated as a judge or gatekeeper here.  To WG14,
> and to C library maintainers, he is an advocate.  Has Alex rejected any
> proposed patches to the Linux man-pages along similar lines as his own
> advocacy?  That would be gatekeeping.
> 
> Alex might consider deputizing a fellow maintainer to handle updates to
> portions of man pages where he has, or expects to have, business before
> WG14.
> 
> Regards,
> Branden



-- 
<https://www.alejandro-colomar.es>
signature.asc (application/pgp-signature, 833 B)