[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <eb013d59-1e84-9d30-a7f6-7236b60a508a@gmail.com>
Date: Sun, 11 Dec 2022 17:30:43 +0100
From: Alejandro Colomar <alx.manpages@...il.com>
To: Stefan Puiu <stefan.puiu@...il.com>
Cc: Guillem Jover <guillem@...rons.org>,
Andrew Clayton <andrew@...ital-domain.net>, linux-man@...r.kernel.org,
Michael Kerrisk <mtk.manpages@...il.com>, Alejandro Colomar
<alx@...nel.org>, Brian Inglis <Brian.Inglis@...tematicsw.ab.ca>,
Rich Felker <dalias@...c.org>, musl@...ts.openwall.com
Subject: Re: [PATCH] memmem.3: Added list of known systems where this is
available
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/>
Download attachment "OpenPGP_signature" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
