Re: the Linux man-pages as an educational tool

Arsen Arsenović <[email protected]> Tue, 04 Aug 2026 17:49:43 +0200
Newsgroups gmane.comp.lib.gnulib.bugs,gmane.linux.man,gmane.comp.lib.glibc.alpha
Message-ID <[email protected]>
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Alejandro Colomar <[email protected]> writes:

> I've thought a bit more about it, and had an idea that might be
> a reasonable compromise.
>
> Here's a sample:
>
> 	 SYNOPSIS
> 	-     #include <memory.h>  // See STANDARDS
> 	+     #include <string.h>  // or <memory.h>; see memory.h(3head)
>=20=09=20
> 	      void *memccpy(size_t n;
> 			    void dest[restrict n], const void src[restrict n],
> 	@@ -34,8 +34,6 @@ ATTRIBUTES
> 	 STANDARDS
> 	      POSIX.1=E2=80=902008.
>=20=09=20
> 	-     ISO C and POSIX declare this function in <string.h>; see memory.h(=
3head).
> 	-
>
> Here's the commit message, which explains why I believe this is
> a reasonable compromise:
>
>     man/man3/: Put first <string.h> in SYNOPSIS, then comment about <memo=
ry.h>
>=20=20=20=20=20
>     This is a compromise between the fact that <string.h> is the standard
>     header and (only slightly) most portable header file for these
>     functions, while hinting at the fact that it might be more appropriate
>     to use <memory.h> where possible.
>=20=20=20=20=20
>     Remove the STANDARDS and NOTES about this, since now the SYNOPSIS
>     contains all the necessary information.  The extra info is in
>     memory.h(3head), which is linked to in the SYNOPSIS.
>
> What do you think?

Why, though?

I think that, in the thread, it was already demonstrated (by Bionic
having an empty memory.h for a time) that nobody includes <memory.h> on
its own and expects to see these functions.  (not that Bionic is that
widely-used; a better test would be checking something like Debian
codesearch)

As I've noted before, what header provides what declaration is also
largely inconsequential.

So, the only effect of this can be to create new cases where <memory.h>
is included, for no gain.

It doesn't really matter that memory.h is only slightly less portable,
IMO.  It is unused, to the point where Autoconf recommends not using it,
and no longer bothers checking whether 'mem*' functions are also present
in string.h.

Is suddenly reviving a dead header to copy a few declarations of
functions well known to be part of string.h into it not just unneeded
churn?  Especially as program code would (nearly?) always need to do:

  #include <string.h>
  #ifdef HAVE_MEMORY_H
  # include <memory.h>
  #endif
=2D-=20
Arsen Arsenovi=C4=87

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

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

iQECBAEWCgCqFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmpyChcbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw
NjE1MkMyOTQzMDFFQTJDNDkzEBxhcnNlbkBhYXJzZW4ubWUACgkQUsKUMB6ixJME
gQEA01D2PwmgvvI2f9uj57h42CNEzXxFD7a/B1L49MjpPVUA/2ZTeaYM0mPU0Lc2
pH7Oj/h23B32KzDuoEOrMsDs374E
=X27n
-----END PGP SIGNATURE-----
--=-=-=--