All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Puiu <stefan.puiu@gmail.com>
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: Guillem Jover <guillem@hadrons.org>,
	Andrew Clayton <andrew@digital-domain.net>,
	linux-man@vger.kernel.org,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Alejandro Colomar <alx@kernel.org>,
	Brian Inglis <Brian.Inglis@systematicsw.ab.ca>,
	Rich Felker <dalias@libc.org>,
	musl@lists.openwall.com
Subject: Re: [PATCH] memmem.3: Added list of known systems where this is available
Date: Thu, 24 Nov 2022 20:57:02 +0200	[thread overview]
Message-ID: <CACKs7VCNh=bxV8waEPc=Gzps+0Q3xYgrX-LbB-1LBOTzdc_9eg@mail.gmail.com> (raw)
In-Reply-To: <50485f46-99d0-69ee-0882-7e403334080c@gmail.com>

Hi,

On Wed, Nov 23, 2022 at 3:16 PM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
>
> Hi all!
>
[... snipped ...]
> >
> > Not sure if it's the job of Linux man-pages to document when other
> > OSes started supporting certain APIs. That info has to be maintained,
> > updated etc. People can always read the man pages of other systems,
> > right? Maybe it's worth only pointing out when an interface is
> > Linux-only, or the Linux implementation diverges significantly.
>
> The good thing is that in most cases, it's either something in POSIX (for which
> I gon't care at all if Apple Libc or another-weirdo-libc decide to not support
> it), or it's a Linux-only function.
>
> So, there are few functions or syscalls that are generally available but are not
> in POSIX, and it might be interesting to document that they're effectively as
> portable as anything POSIX.  Maybe even POSIX editors read this and decide to
> add it.
>
> In those cases, we still need to decide what we care about or not.

Aah OK, so memmem is non-standard, there is no standard to point to.
Do other OSes provide this kind of info? I don't see anything about
portability in the OpenBSD man page (https://man.openbsd.org/memmem),
only "memmem() is a GNU extension". The FreeBSD man page
(https://www.freebsd.org/cgi/man.cgi?query=memmem&manpath=FreeBSD+13.1-RELEASE+and+Ports)
does mention Linux, but only to mention that memmem was broken in old
versions of Linux libc (nothing about current Linux); it also has the
'GNU extension' mention. Interestingly, I don't see the mention of the
function being a GNU extension in the Linux version.

Have you checked, are there many such functions? Do you plan to add
this info for all of them?

>
> Musl libc is definitely a first-class citizen these days in Linux distributions.
>   I would start documenting them in the project at large if someone from musl
> provides patches (I discussed this some time ago, but can't remember with who).
> Rich, if you would like to discuss about this, we can have some chat.
>
> >
> > For musl and other libcs, I think the man pages already document some
> > instances where their behavior diverges from glibc.
>
> As said, for musl, I'd document them officially, if there's anyone interested
> enough to send patches.
>
> For other libcs, we have to decide if they're important enough, and probably
> decide on a case-by-case basis.
>
> Michael tried to have some decent coverage of non-GNU/Linux systems, both in the
> man-pages and in his TLPI book.  It's a useful thing.  So much that sometimes
> you don't even need to read other systems' pages at all to know how portable is
> a GNU/Linux function.

I know. But not sure how much Linux docs should cover about other
OSes, which are also constantly changing (and have their own fine
docs).

As always, just my 2c,
Stefan.

>
> So, I'd like to get opinions on interest about documenting details about:
>
> - newlib (I never heard about it before; is it a widespread thing? do you think
> it's useful?)
> - Apple Libc (I still don't like it, but I must admit that it's relevant, and
> being open source, it's more palatable)
> - bionic (does anyone know if that's useful at all for anyone at all?)
>
> Support for those wouldn't go as far as musl or glibc.  For now it would only be
> for memmem(3).
>
>
> Cheers,
>
> Alex
>
> --
> <http://www.alejandro-colomar.es/>

  parent reply	other threads:[~2022-11-24 18:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10  0:13 [PATCH] memmem.3: Added list of known systems where this is available Andrew Clayton
2022-11-10 11:36 ` Alejandro Colomar
2022-11-10 12:58   ` Andrew Clayton
2022-11-10 14:16     ` Alejandro Colomar
2022-11-22 23:11   ` Guillem Jover
2022-11-23 12:52     ` Stefan Puiu
2022-11-23 13:16       ` Alejandro Colomar
2022-11-23 14:55         ` [musl] " Jeffrey Walton
2022-11-23 15:11           ` Alejandro Colomar
2022-11-24 18:57         ` Stefan Puiu [this message]
2022-12-11 16:30           ` Alejandro Colomar
2022-11-10 23:31 ` [PATCH v2] memmem.3: Add " Andrew Clayton
2022-11-10 23:59   ` Alejandro Colomar
2022-11-11  0:04     ` Andrew Clayton
2022-11-11  0:05       ` Alejandro Colomar
2022-11-11  0:20         ` Andrew Clayton
2022-11-11  0:21           ` Alejandro Colomar
2022-11-11  1:27 ` [PATCH v3] " Andrew Clayton
2022-11-11  1:35   ` Alejandro Colomar
2022-11-11 18:09   ` Brian Inglis
2022-11-24 19:13 [PATCH] memmem.3: Added " Brian Inglis

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='CACKs7VCNh=bxV8waEPc=Gzps+0Q3xYgrX-LbB-1LBOTzdc_9eg@mail.gmail.com' \
    --to=stefan.puiu@gmail.com \
    --cc=Brian.Inglis@systematicsw.ab.ca \
    --cc=alx.manpages@gmail.com \
    --cc=alx@kernel.org \
    --cc=andrew@digital-domain.net \
    --cc=dalias@libc.org \
    --cc=guillem@hadrons.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=musl@lists.openwall.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.