Re: the Linux man-pages as an educational tool
Alejandro Colomar <[email protected]> Sun, 2 Aug 2026 13:47:50 +0200
| Newsgroups | gmane.linux.man,gmane.comp.lib.gnulib.bugs,gmane.comp.lib.glibc.alpha |
|---|---|
| Message-ID | <am8tWQ4m2AsEudA_@devuan> |
Hi Collin, > > Date: 2026-08-01 18:49:03-0700 > > From: Collin Funk <[email protected]> > > > > But myself and likely many others who have commented on this thread do > > not agree that strings.h is a bad name. Or that general memory related > > functions, which are used on strings a large portion of the time, need a > > separate header. BTW, this typo reminds me that we have some more evidence. <strings.h> has existed for a long time in parallel to <string.h>, and some functions are documented as being provided by it instead of by <string.h>. An example is strcasecmp(3). In practice, both <string.h> and <strings.h> provide strcasecmp(3): alx@devuan:~/tmp$ cat s.c #include <string.h> int main(void) { void *p = strcasecmp; } alx@devuan:~/tmp$ gcc -Wall -Wextra -Wno-unused s.c alx@devuan:~/tmp$ Every now and then, people wonder about this non-standard header file, but no cats were harmed by that. Claiming that <memory.h> would be much different is unreasonable, IMO. Cheers, Alex -- <https://www.alejandro-colomar.es>
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmpvLmAACgkQ64mZXMKQ wqk9tA//VrgaF6dEYAAwlF165cstg8mIitHgP/0CM4aiCrSV4MuP5Siw4oGXOWWg Gb4tKADuFufQTIrkm/gM0EQ4qFPyyzGeDoaoFsVvNcLnp8vocI5zuoHS0e8mWKR1 dNWFK8fb6MgZDDudWtntnnoWKUhzoNOAouzQCkQ5QJOuPe77RhzPiDVvo9ZwRMVo nFcYSH3YY7Arap2oyy1hF8HEEZE/DJ2k5AhrUeMb0/o8dWFEMAzc9GxuCJLo2Pod 1RWh6KlCVRFJdUWpuu18Yu8Z9cImxyRLhf+36VWDd7V9JaUs2WE1pQjLh9KX5yb5 CWz0tzmHoTNL8zIl9a4OffJ1JkJAVDthgncrlpAhR5HLBmLKGSHyXlUUjK0q4ZEF n7U0ntXN6S/O230+9WUzyAvmpDLZwG0qYtkPAAH+/1CVSCu4Z42aMRoJUxeiTUtl B4IOu0MFB6QoVEYpdt/kcENaFdGHwfhfUt+a9PL8X5Vqq5859RxwEBwjRWvws+ua kDvPQAkJukQ0WzYqvhnZ2vedS87UkZ4OmteGAkpXr2bl1JJlSrHr2h94WCtznu5a rWcokNy2ROK3GZ3aJwzN9DS3sje5rHpnDTWwdgp9E+uX0WcPnoZGP0Qts1pjVGo2 UbreZ1Y5yVO1FqSa7SWtNe45tL4WQh6BU3AGtnyghidMpPvkPUo= =8AHW -----END PGP SIGNATURE-----