All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Joseph Myers <josmyers@redhat.com>
Cc: 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:05:44 +0200	[thread overview]
Message-ID: <am0ax4Oe6--0Deco@devuan> (raw)
In-Reply-To: <e1031c2c-37eb-3cee-8bf0-f3285803d4e3@redhat.com>

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

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.

That's 37 years.  During these 37 years we have gathered a lot of
experience and data about this.  And the conclusion is that it was
a huge mistake.  Programmers have struggled to understand this, and
continue struggling.  This is not about new programmers.  This includes
programmers that have been around for decades, including maintainers of
core projects in which we all rely.

The move from <memory.h> to <string.h> seems to be entirely unjustified,
and was unilateral by the C Committee for C89 (from what I can see).

It's easy to see that all these problems about string handling would
probably be significantly less if these functions had never been
moved to <string.h>.

I agree that changing stuff that has been unchanged for decades should
usually be avoided, be done very carefully, and with strong
justification.  But in this case, it's justified, and doesn't break any
existing or new code, because <memory.h> has been provided since
forever.


Cheers,
Alex

> 
> I'd rather we add a mandatory deprecation warning to memory.h in glibc.
> 
> -- 
> Joseph S. Myers
> josmyers@redhat.com
> 

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

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

  parent reply	other threads:[~2026-07-31 22:05 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
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 [this message]
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=am0ax4Oe6--0Deco@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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.