mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Alejandro Colomar <alx.manpages@gmail.com>
To: Stefan Puiu <stefan.puiu@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: [musl] Re: [PATCH] memmem.3: Added list of known systems where this is available
Date: Sun, 11 Dec 2022 17:30:43 +0100	[thread overview]
Message-ID: <eb013d59-1e84-9d30-a7f6-7236b60a508a@gmail.com> (raw)
In-Reply-To: <CACKs7VCNh=bxV8waEPc=Gzps+0Q3xYgrX-LbB-1LBOTzdc_9eg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2889 bytes --]

Hi Stefan,

On 11/24/22 19:57, Stefan Puiu wrote:
> 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.

The Linux man-pages have a little bit more of tradition talking about other 
systems in that regard.

> 
> Have you checked, are there many such functions?

No, I didn't.

> Do you plan to add
> this info for all of them?

No.  I don't have the time to add this information for all such functions.
But if someone sends a patch, _and_ it only mentions free software libraries 
(i.e., macOS no, but Apple libc yes), and the function is not yet in POSIX, and 
the function is something very useful that might be ported to other systems if 
many programs use it,
then I will accept such a path.

memmem(3) is an example of such a function, so such patches for it are welcome.

> 
>>
>> 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).

Support for a function is something that usually is only added.  I'd be careful 
of only adding such info for functions that I expect to grow in popularity, 
maybe even they're added to a future POSIX (I expect this can happen with memmem(3))

> 
> As always, just my 2c,
> Stefan.

Cheers,

Alex

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

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

      reply	other threads:[~2022-12-11 16:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20221110001318.10696-1-andrew@digital-domain.net>
     [not found] ` <853fa349-8e78-8ce8-f76f-79b4b9353913@gmail.com>
     [not found]   ` <Y31XOPOsB932l0cd@thunder.hadrons.org>
     [not found]     ` <CACKs7VAQsxDc2XrsAYSEbA9eqRnLHuXykVmNTit+tCFMyGLCwA@mail.gmail.com>
2022-11-23 13:16       ` Alejandro Colomar
2022-11-23 14:55         ` Jeffrey Walton
2022-11-23 15:11           ` Alejandro Colomar
2022-11-23 15:33         ` [musl] " Shiz
2022-11-30 19:39           ` enh
2022-12-09 20:25             ` Alejandro Colomar
2022-11-24 18:57         ` [musl] " Stefan Puiu
2022-12-11 16:30           ` Alejandro Colomar [this message]

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=eb013d59-1e84-9d30-a7f6-7236b60a508a@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=Brian.Inglis@systematicsw.ab.ca \
    --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 \
    --cc=stefan.puiu@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).