Linux Manual Pages development
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Sam James <sam@gentoo.org>
Cc: Joseph Myers <josmyers@redhat.com>,
	linux-man@vger.kernel.org,  Keith Bostic <keith@bostic.com>,
	Mark Harris <mark.hsj@gmail.com>,
	 Nevin Liber <nevin@cplusplusguy.com>,
	JeanHeyd Meneide <phdofthehouse@gmail.com>,
	 Christopher Bazley <chris.bazley.wg14@gmail.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	 Iker Pedrosa <ipedrosa@redhat.com>,
	"Evgeny Grin (Karlson2k)" <k2k@drgrin.dev>,
	 Kees Cook <keescook@chromium.org>,
	bug-gnulib@gnu.org, libc-alpha@sourceware.org
Subject: Re: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>
Date: Sat, 1 Aug 2026 00:18:58 +0200	[thread overview]
Message-ID: <am0dFT38yXK_ch_o@devuan> (raw)
In-Reply-To: <87ik5uesfg.fsf@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]

Hi Sam,

> Date: 2026-07-31 22:54:27+0100
> From: Sam James <sam@gentoo.org>
>
> Alejandro Colomar <alx@kernel.org> writes:
> 
> > Hi Joseph,
> >
> >> Date: 2026-07-31 21:23:35+0000
> >> From: Joseph Myers <josmyers@redhat.com>
> >>
> >> I think it's irresponsible to use the man-pages project to promote 
> >> personal idiosyncratic ideas like this in preference to what's been the 
> >> standard location of functions since 1989.
> >> 
> >> I'd rather we add a mandatory deprecation warning to memory.h in glibc.
> >
> > I hope you don't; it'd be a gratuitous breaking change.
> >
> 
> Yet this change has the same effect, just people will see it themselves
> rather than the compiler telling them, and go around sending patches to
> change it.

IME, people don't go changing includes unless they need something it's
not available in the already-included header files.

Analysis of includes is quite complex, and there are tools for that
--iwyu(1)--.  As long as those tools don't start complaining --and they
won't-- [1], I find it quite unlikely that people will start changing
includes in existing code.

This is rather something that will affect new code (new source files).

[1]	iwyu(1) works in a way that it allows a number of headers to
	provide a symbol.  If no header provides the symbol, then it
	will recommend the best header for it; but if a header that
	provides the symbol is already there, it won't complain.

> The man pages should reflect what the standard currently says, not what
> you'd like it to say.

Not exactly; the standard is a good guideline, but sometimes it's off.
We have vendor extensions, which are well documented, and when the
standard is bogus, the extensions take over the page.

FWIW, the information from the standard is still there.

	$ MANWIDTH=64 mansectf STANDARDS man3/memcpy.3 | cat
	memcpy(3)           Library Functions Manual          memcpy(3)

	STANDARDS
	     C11, POSIX.1‐2008.

	     ISO C and POSIX declare this function in <string.h>.

	Linux man‐pages (unreleased) (date)                   memcpy(3)

I've just removed it from the front of the page (SYNOPSIS), but it's
still there, because of course, we must document the standard alongside
the extension.

> We had the same problem with e.g. stripping "C89"
> everywhere.

Sorry for that one; it was a useful change, though.  Now we have better
manual pages than we had back then, regarding standards.  I hope you
realize about that.  It triggered discussion, and a careful review of
the text, which resulted in a good change after all.

> People want it to reflect what the standard says.

And it still does.


Have a lovely night!
Alex

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-07-31 22:19 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31 21:18 [PATCH 0/2] alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al Alejandro Colomar
2026-07-31 21:18 ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> Alejandro Colomar
2026-07-31 21:23   ` Joseph Myers
2026-07-31 21:28     ` Alejandro Colomar
2026-07-31 21:54       ` Sam James
2026-07-31 22:18         ` Alejandro Colomar [this message]
2026-08-01  0:12           ` Alejandro Colomar
2026-07-31 21:51     ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) G. Branden Robinson
2026-07-31 21:59       ` on the irresponsibility of pursuing C language reform Sam James
2026-07-31 22:24         ` G. Branden Robinson
2026-07-31 23:19           ` Alejandro Colomar
2026-07-31 22:10       ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) Joseph Myers
2026-07-31 22:21         ` Alejandro Colomar
2026-07-31 22:28           ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> G. Branden Robinson
2026-07-31 22:42           ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) Joseph Myers
2026-07-31 22:52             ` Alejandro Colomar
2026-07-31 23:11               ` Joseph Myers
2026-07-31 23:32                 ` G. Branden Robinson
2026-07-31 23:45                 ` on the irresponsibility of pursuing C language reform (was: " Alejandro Colomar
2026-07-31 23:08             ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> G. Branden Robinson
2026-07-31 23:28               ` Joseph Myers
2026-07-31 23:57                 ` G. Branden Robinson
2026-08-01  0:06                   ` Alejandro Colomar
2026-07-31 22:05     ` Alejandro Colomar
2026-07-31 22:16       ` Joseph Myers
2026-07-31 22:33         ` Alejandro Colomar
2026-07-31 23:48     ` [PATCH 1/2] man/man3/{mem, strn}*(): " Collin Funk
2026-07-31 23:52       ` Alejandro Colomar
2026-08-01  0:01         ` Alejandro Colomar
2026-07-31 21:19 ` [PATCH 2/2] man/man*/{string.3,memory.h.3head}: Move functions to a new page memory.h(3head) Alejandro Colomar
2026-07-31 21:20 ` [PATCH 0/2] alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al Alejandro Colomar
2026-08-01  0:25 ` [PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h> Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=am0dFT38yXK_ch_o@devuan \
    --to=alx@kernel.org \
    --cc=bug-gnulib@gnu.org \
    --cc=chris.bazley.wg14@gmail.com \
    --cc=ipedrosa@redhat.com \
    --cc=josmyers@redhat.com \
    --cc=k2k@drgrin.dev \
    --cc=keescook@chromium.org \
    --cc=keith@bostic.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mark.hsj@gmail.com \
    --cc=nevin@cplusplusguy.com \
    --cc=phdofthehouse@gmail.com \
    --cc=sam@gentoo.org \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox