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

--owvoh3xzakurq64c
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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-31T22:42:00+0000, Joseph Myers wrote:
> Standards involve accepting agreed compromises that might not have
> been your first choice, rather than endlessly relitigating past
> disputes without new evidence or changed circumstances.  In this case,
> the choice of where to put the functions in C89 was an agreed
> compromise that implicitly obsoleted the previous location, and should
> have put an end to any arguments that <string.h> was a bad location
> for those functions in the absence of clear new evidence.  We have
> plenty of clear evidence for confusion about strn*; we don't about
> mem*.

What are some good ways to gather evidence that:

* ...C programmers since 1989 have gotten better at recognizing when
  they're dealing with "memory buffers" versus "strings"?
* ...that the header file's name has aided or frustrated that
  recognition process?
* ...that consequences of whatever confusion persists are more severe
  than the C Committee measured in 1989?

You can tell by my phrasing which way I _suspect_ the evidence points,
but I'll openly admit I don't have quantiative data.

But I think bringing such information to bear makes a stronger case than
a simple appeal to 37 years of precedent.

Occasionally, matters get relitigated because they had been wrongly
decided.  I appreciate the trend since 2000 or so of Stroustrup (with
respect to C++) and the Austin Group (with respect to POSIX) becoming
more open about where the bodies are buried, and how certain
standardization decisions have been reversed (through deprecation,
withdrawal, and similar) because a powerful vendor took its leave and
was no longer around to filibuster constructive development until its
demands were met.

I seem to recall Stroustrup calling out Sun Microsystems by name in the
4th edition of his main C++ book.  (Something to do with the exception
propagation mechanism, I think.)

I suggest to WG14 that a good way to reduce relitigation is to
candidly disclose in informative sections of the standard corresponding
to applicable topics, where the committee as constituted at the time of
issue has reached exhaustion with a matter.  (Though I wonder if ISO
would insist that such language be ripped out.)

I followed the C23 standarization process closely, and it looks as if
the National Bodies (NB) very nearly fought WG14 to exhaustion regarding
trigraphs.  I was greatly relieved that you guys won that one.

Back to the topic at hand, in data processing we tend to strongly
distinguish three forms of storage management:

1.  base and bounds (mem*)
2.  delimited (if with null bytes, str[^n]*)
3.  fixed-field (strn*, but not very consistently)

=46rom one perspective, 1 and 3 are really the same, but from another
they're not, because, as some thousands of CVEs have shown, programmers
thinking of case 3 tend to assume that the field will be populated with
elements that are "well-behaved" in some way, whereas in case 1 they
tend even more strongly to be conscious that the storage could be
populated with arbitrary or even malicious garbage.

Do your impressions match mine in this area?

Regards,
Branden

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

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

iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmptKvgACgkQ0Z6cfXEm
bc5Dag/+Od6oW0Jvhu2kr10hy7oQYdfUpsyXWUBNKiRH+umAoaZDyr8zMMlEk5aK
Le74Du6WV2IBz4R6EZeuIfCAXMge2/JoSoJq6kFQ7pz5EVC0UqZV+nq0ovCEQQXE
Asjz1qYblVtExtb2tYvFp17NSHl1D26FwRedfLeNb+V57fMXRQWyZbJQcxDM+1ZK
Ikv+ChNIjAYAiUILDI4w8vlgXUbrF8oMcviy2HjxFxyuGVlWnqbfQRMV1XVtDFJn
s7hxzuz8q0qtu9pVo6ZDd0i8ycDYAOZ8StQbC5xUwbZ7ndNFKA0OY2duH3FnCTYZ
1/v/2o0Yn1F8ekRf2ehRVWSoNlhSD/Oo6yUb9DiRBMd7TAzXmrlwzNkQzjLa5rzA
BQ3el6k8AO3rBKxkQMbcJ9NzC7fUyy6hibrxBdfw8dvJvNAz1vAfuRtCMtW4r5xE
5z1AYWJw2PjMrDq4DjLPj4RFB3nH6uhSH4CXRbx7urOIHpiwySFwLK4M3bpCJ+pc
4FZVz71zi9jLElx7a2krHAZjhH457qqVtF7ezPYC4QxEcK10tlkLrdlrihvfBiDq
MHXlnsDMBUxKNr9VfHrtwNEtyDHEHZrpCv15IbO9p8Q227Qtmpr+B6o9uUGdilK9
v0yANMvyj6GKcm7vhiTWxKmP9UnMDrDZ7X8CeGdZBvVi2xeRcTU=
=05+0
-----END PGP SIGNATURE-----

--owvoh3xzakurq64c--