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

--catlbfwvx4mvmhzy
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Subject: Re: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS:
 Document these as provided by <memory.h>
MIME-Version: 1.0

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.

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

--catlbfwvx4mvmhzy
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmptNnQACgkQ0Z6cfXEm
bc7oeQ/7BM50b0QhLB/1PEMxL8YOXTqy7lTq+u99G8F70UubgyHHvZuFUE13Ofjw
gJHIBEGynd0Rew4PP1OR0XbBy2+CDskj6ggNNkfnPdGudWiXzHODNBndxYAIxuCZ
6QPP2nteKSh31ufEgJtDZhmAFtb5Rcn25fs70vmbcHu/heRUJGb/MvHn0/YBLEVb
IMixyKUu6g5V1TuimUIUPtggcerGMmuq9Ja2X8we8AIQy/6RBRjC+DdqJHUMA7KB
GUYyZoQTDOCw5YaoX6TeA2wfWqwDKi6fNB8dXI21ygRh2TYmpnWf00innKkRFARn
EOLQTngrqqpn8QjOSj4RwHhNMTuHXzqkliM3JFLIs7WP8Jt1IeW55eNMmkKpzs/c
XBuhDL0Cv0xRpaRNS08UTFQvpmxm56+EwBG3XjKpKJDvLDUZTDY5NwFekK54CsBQ
pNGnTGtwFnQAV1JSju2ZiVHKRUy3/Gb4J7q3xt3A1Gc4bW37wJZRMioQmDdXIHNf
AlHimkZj8yP2ix/cnFVC3e/t0ZYxT+gh4VMTGgwtbJRbJ6hqdQ8TWU2Vp6ZaEsPh
seXi+WOd2A4jYqOfIC33bYoUUJs7CTdRlfZs9n4rZzPG6awX7wPHB9xZKqY756oG
1RjHqp8jRWUi3Rkq/MUAH+tUsCJkCuGxRWhRzEVx6QNcDoEPHzw=
=0YmB
-----END PGP SIGNATURE-----

--catlbfwvx4mvmhzy--