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 org.kernel.vger.linux-man
Message-ID <am04Lt2WQ2wNonuz@devuan>
--zorhsguq6bpf334p
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
From: Alejandro Colomar <[email protected]>
To: "G. Branden Robinson" <[email protected]>
Cc: Joseph Myers <[email protected]>, [email protected], 
	Keith Bostic <[email protected]>, Mark Harris <[email protected]>, 
	Nevin Liber <[email protected]>, JeanHeyd Meneide <[email protected]>, 
	Christopher Bazley <[email protected]>, "Serge E. Hallyn" <[email protected]>, 
	Iker Pedrosa <[email protected]>, "Evgeny Grin (Karlson2k)" <[email protected]>, 
	Kees Cook <[email protected]>, [email protected], [email protected]
Subject: Re: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS:
 Document these as provided by <memory.h>
Message-ID: <am04Lt2WQ2wNonuz@devuan>
References: <[email protected]>
 <784288e704183a4297aeaa3d13af8edab18bc1ea.1785532392.git.alx@kernel.org>
 <[email protected]>
 <20260731215122.4p4aepsbgeoibx74@illithid>
 <[email protected]>
 <am0fnb4BMRrTajqx@devuan>
 <[email protected]>
 <20260731230847.prx4gay3ejvqdy6q@illithid>
 <[email protected]>
 <20260731235747.7bwyb2xul4zhryuu@illithid>
MIME-Version: 1.0
In-Reply-To: <20260731235747.7bwyb2xul4zhryuu@illithid>

Hi Branden,

> Date: 2026-07-31 18:57:47-0500
> From: "G. Branden Robinson" <[email protected]>
>
> Hi Joseph,
>=20
> 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.
>=20
> I agree that there is a _potential_ moral hazard here.
>=20
> > 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.)
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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

>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Regards,
> Branden



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

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

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

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmptOJoACgkQ64mZXMKQ
wqnunA/+P9WXqtIgqGIIDP3MJ9cJnYOjYvrnwci6O0hL/QySbXMuaNrRaaPuFd6X
6DZKbuIWanwPzSYPFIa/zFA6Ndct+qG36H/vvh16PNPxwmjsJmWwfVMJXdIYH4o5
tXIlINLDIZvxXmML8ugqADIa5HWKQqm/Joe56Y28QVXZoyreQcxWW25GyvXPMnrB
OV5I7P7SMxa7rLG+lEAPAa3wngvRQ7bPxVQ7ox36C6cDkCNK9xFqCt5IL932nrQl
fXMUhpOp7p7rW4l5K0hiMKY77t2NXbHxDo/GsZqC6gq9iQpSrhBCLumfbAEpUP0u
AV+9JM7Q1q4/VIsEFKDJ1903znU78+njxf6NMzyQf0zBNK8NVi9dK634A5jFaAya
9NCf80oH5pRoXeCDrVK3d789RcrFaB0wAPUeFcSjRvbmllTx509oaWWM2PlgCU5U
OMItTd/coULo8yWb1gnW9ew3SC1dhg0A9r4kHZzQDUayPzSr1xBZ02WMM473rG5s
Gf4v8VtQSonlwLas3tKLr8VO0uDoMST9vsXRZQGH5r/R6J7bI1eCz3j6KRR5YC+f
502jRji+kY8l9vQeqX/OpDT9LKY3FPhjzQGe7WDU88veeEUTXcYzHRj7kUFS8Scb
iDAlJxF3QIsY65t7W11lwoUxUlwFnttVgR2lqWx5ZYSySgI/auI=
=i08C
-----END PGP SIGNATURE-----

--zorhsguq6bpf334p--