[PATCH] memmem.3: Added list of known systems where this is available

[PATCH] memmem.3: Added list of known systems where this is available

[Andrew Clayton]

While looking at which systems provide memmem(3) I have been able to
discern the following:

  musl libc since v0.9.7
  bionic since Android 9

  FreeBSD since 6.0
  OpenBSD since 5.4
  NetBSD
  macOS
  Illumos

For macOS and Illumos I checked the memmem(3) man page on those systems.
For the rest there are links below to on-line man pages or commit logs.

Where I could determine what version memmem(3) was introduced, I've
noted that in the man page.

Link: <http://git.musl-libc.org/cgit/musl/commit/src/string/memmem.c?id=c86f2974e2acd330be2d587173dd4dd56db82e22>
Link: <https://android.googlesource.com/platform/bionic/+/android-9.0.0_r3/libc/bionic/memmem.cpp>
Link: <https://www.freebsd.org/cgi/man.cgi?query=memmem&sektion=3&format=html>
Link: <https://man.openbsd.org/memmem.3>
Link: <https://anonhg.netbsd.org/src/diff/96a37d536271/common/lib/libc/string/memmem.c>
Suggested-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <andrew@digital-domain.net>
---
 man3/memmem.3 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/man3/memmem.3 b/man3/memmem.3
index 134dffab0..1f58ffffd 100644
--- a/man3/memmem.3
+++ b/man3/memmem.3
@@ -58,7 +58,9 @@ T}	Thread safety	MT-Safe
 .sp 1
 .SH STANDARDS
 This function is not specified in POSIX.1,
-but is present on a number of other systems.
+but is present on a number of other systems,
+including: musl libc 0.9.7 & bionic Android 9;
+FreeBSD 6.0, OpenBSD 5.4, NetBSD, macOS & Illumos.
 .SH BUGS
 .\" This function was broken in Linux libraries up to and including libc 5.0.9;
 .\" there the
-- 
2.38.1

Re: [PATCH] memmem.3: Added list of known systems where this is available

[Alejandro Colomar]

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

Hi Andrew!

On 11/10/22 01:13, Andrew Clayton wrote:
> While looking at which systems provide memmem(3) I have been able to
> discern the following:
> 
>    musl libc since v0.9.7
>    bionic since Android 9
> 
>    FreeBSD since 6.0
>    OpenBSD since 5.4
>    NetBSD
>    macOS
>    Illumos

Although for the page itself I wouldn't add the dates, I think it's useful to 
include the years of those releases in the commit message (when known).

musl 0.9.7 is from 2012.
FreeBSD 6 is from 2005.
OpenBSD 5.4 is from 2013.

Please include that, if you don't mind.

> 
> For macOS and Illumos I checked the memmem(3) man page on those systems.
> For the rest there are links below to on-line man pages or commit logs.
> 
> Where I could determine what version memmem(3) was introduced, I've
> noted that in the man page.
> 
> Link: <http://git.musl-libc.org/cgit/musl/commit/src/string/memmem.c?id=c86f2974e2acd330be2d587173dd4dd56db82e22>
> Link: <https://android.googlesource.com/platform/bionic/+/android-9.0.0_r3/libc/bionic/memmem.cpp>
> Link: <https://www.freebsd.org/cgi/man.cgi?query=memmem&sektion=3&format=html>
> Link: <https://man.openbsd.org/memmem.3>
> Link: <https://anonhg.netbsd.org/src/diff/96a37d536271/common/lib/libc/string/memmem.c>
> Suggested-by: Alejandro Colomar <alx@kernel.org>
> Signed-off-by: Andrew Clayton <andrew@digital-domain.net>
> ---
>   man3/memmem.3 | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/man3/memmem.3 b/man3/memmem.3
> index 134dffab0..1f58ffffd 100644
> --- a/man3/memmem.3
> +++ b/man3/memmem.3
> @@ -58,7 +58,9 @@ T}	Thread safety	MT-Safe
>   .sp 1
>   .SH STANDARDS
>   This function is not specified in POSIX.1,
> -but is present on a number of other systems.
> +but is present on a number of other systems,
> +including: musl libc 0.9.7 & bionic Android 9;

I prefer 'and' rather than '&'.

> +FreeBSD 6.0, OpenBSD 5.4, NetBSD, macOS & Illumos.

Also, we use Oxford commas in the project, which means having a comma before the 
'and' if there are at least 3 items in the list.

For the commit message, it's interesting to note macOS and Bionic, for 
speleology purposes.  However, I'm opposed to adding them to the page itself 
because of the following:

-  macOS is not free software.  I refuse to reference nonfree software on this 
project.
-  Android is not a real Unix system, in that you can't even program in C in 
there, unless you're Google or have hacked your system.  It's not friendly to us 
programmers, so we don't need to be friendly to it.  I don't want to be 
cluttering the pages with information that is irrelevant to normal users.

Thank you for the patch!

Cheers,

Alex

>   .SH BUGS
>   .\" This function was broken in Linux libraries up to and including libc 5.0.9;
>   .\" there the

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

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

Re: [PATCH] memmem.3: Added list of known systems where this is available

[Andrew Clayton]

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

On Thu, 10 Nov 2022 12:36:47 +0100
Alejandro Colomar <alx.manpages@gmail.com> wrote:

> Although for the page itself I wouldn't add the dates, I think it's useful to 
> include the years of those releases in the commit message (when known).
> 
> musl 0.9.7 is from 2012.
> FreeBSD 6 is from 2005.
> OpenBSD 5.4 is from 2013.
> 
> Please include that, if you don't mind.

Will do.

[...]

> For the commit message, it's interesting to note macOS and Bionic, for 
> speleology purposes.  However, I'm opposed to adding them to the page itself 
> because of the following:
> 
> -  macOS is not free software.  I refuse to reference nonfree software on this 
> project.

In that case you might want to remove references to the following (as
it looked OK to reference proprietary UNIX)

SunOS, Solaris, Irix, AIX, DG/UX, HP-UX, OSF/1, Digital UNIX, Tru64,
SCO (definitely SCO!), and MacOS X (and probably others I missed).

Personally I wouldn't, they're a part of Linux's history... and these
days largely interesting for historical purposes.

Cheers,
Andrew

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

Re: [PATCH] memmem.3: Added list of known systems where this is available

[Alejandro Colomar]

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

Hi Andrew!

On 11/10/22 13:58, Andrew Clayton wrote:
> On Thu, 10 Nov 2022 12:36:47 +0100
> Alejandro Colomar <alx.manpages@gmail.com> wrote:
> 
>> Although for the page itself I wouldn't add the dates, I think it's useful to
>> include the years of those releases in the commit message (when known).
>>
>> musl 0.9.7 is from 2012.
>> FreeBSD 6 is from 2005.
>> OpenBSD 5.4 is from 2013.
>>
>> Please include that, if you don't mind.
> 
> Will do.
> 
> [...]
> 
>> For the commit message, it's interesting to note macOS and Bionic, for
>> speleology purposes.  However, I'm opposed to adding them to the page itself
>> because of the following:
>>
>> -  macOS is not free software.  I refuse to reference nonfree software on this
>> project.
> 
> In that case you might want to remove references to the following (as
> it looked OK to reference proprietary UNIX)

There's no rule.  It can be OK; let me explain a little bit, at least my 
opinion, which I didn't consult to previous maintainers, but seems to be 
somewhat aligned.

If someone reading the list has a different opinion, please manifest yourselves. 
  If you do, also feel free to do so.  I'm not strongly convinced of it; it's 
just the guideline I follow.

> 
> SunOS, Solaris, Irix, AIX, DG/UX, HP-UX, OSF/1, Digital UNIX, Tru64,
> SCO (definitely SCO!), and MacOS X (and probably others I missed).
> 
> Personally I wouldn't, they're a part of Linux's history... and these
> days largely interesting for historical purposes.

So, yes, some decades ago, Linux and other FOSS OSes weren't as widespread as 
they are now, and it was quite useful to know what Solaris and other UNIXes did. 
  Also, some free OSes descend or took features from some of those proprietary OSes.

However, today it's possible to ignore that those exist, for most purposes.

So, as a rough guideline, I wouldn't document macOS providing a function 
available in all main free OSes, but I would document something like the nasty 
thing they did with pivot_root(2)[1], which can hurt us free world programmers.

Current practice with references to macOS seems to be consistent with that:

$ grep -rni macos
man3/termios.3:1166:FreeBSD and NetBSD and HP-UX and MacOS ignore the value of
man3/fopen.3:84:the beginning of the file, but for Android/BSD/MacOS, the
man3/remquo.3:63:.\" MacOS 10: return 7 bits
man3/pthread_attr_setstacksize.3:55:.\" e.g., MacOS
Changes.old:16031:            On MacOS X at least, pthread_attr_setstacksize(3) 
can fail
Changes.old:49338:            MacOS has the ambiguous "The stream is positioned 
at the end of
$

Those few cases refer to incompatibilities in macOS that might break otherwise 
fine programs.

And as you said, I'm not removing any existing references, for historical purposes.


[1]: <https://github.com/nginx/unit/issues/737>


> 
> Cheers,
> Andrew

Cheers,
Alex

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

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

[PATCH v2] memmem.3: Add list of known systems where this is available

[Andrew Clayton]

While looking at which systems provide memmem(3) I have been able to
discern the following:

  musl libc since v0.9.7 (2012)
  bionic since Android 9 (2018)

  FreeBSD since 6.0 (2005)
  OpenBSD since 5.4 (2013)
  NetBSD
  macOS
  Illumos

For macOS and Illumos I checked the memmem(3) man page on those systems.
For the rest there are links below to on-line man pages or commit logs.

Where I could determine what version memmem(3) was introduced, I've
noted that in the man page.

Link: <http://git.musl-libc.org/cgit/musl/commit/src/string/memmem.c?id=c86f2974e2acd330be2d587173dd4dd56db82e22>
Link: <https://android.googlesource.com/platform/bionic/+/android-9.0.0_r3/libc/bionic/memmem.cpp>
Link: <https://www.freebsd.org/cgi/man.cgi?query=memmem&sektion=3&format=html>
Link: <https://man.openbsd.org/memmem.3>
Link: <https://anonhg.netbsd.org/src/diff/96a37d536271/common/lib/libc/string/memmem.c>
Suggested-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <andrew@digital-domain.net>
---

 v2:
  - Remove references to bionic and macOS from the man page
  - Convert & to and
  - Use Oxford comma
  - Add dates where known to the commit message
  - Use present tense for the subject line

 man3/memmem.3 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/man3/memmem.3 b/man3/memmem.3
index 134dffab0..cb0d3e195 100644
--- a/man3/memmem.3
+++ b/man3/memmem.3
@@ -58,7 +58,9 @@ T}	Thread safety	MT-Safe
 .sp 1
 .SH STANDARDS
 This function is not specified in POSIX.1,
-but is present on a number of other systems.
+but is present on a number of other systems,
+including: musl libc 0.9.7; FreeBSD 6.0, OpenBSD 5.4,
+NetBSD, and Illumos.
 .SH BUGS
 .\" This function was broken in Linux libraries up to and including libc 5.0.9;
 .\" there the
-- 
2.38.1

Re: [PATCH v2] memmem.3: Add list of known systems where this is available

[Alejandro Colomar]

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

Hi Andrew,

On 11/11/22 00:31, Andrew Clayton wrote:
> While looking at which systems provide memmem(3) I have been able to
> discern the following:
> 
>    musl libc since v0.9.7 (2012)
>    bionic since Android 9 (2018)
> 
>    FreeBSD since 6.0 (2005)
>    OpenBSD since 5.4 (2013)
>    NetBSD
>    macOS
>    Illumos
> 
> For macOS and Illumos I checked the memmem(3) man page on those systems.
> For the rest there are links below to on-line man pages or commit logs.
> 
> Where I could determine what version memmem(3) was introduced, I've
> noted that in the man page.
> 
> Link: <http://git.musl-libc.org/cgit/musl/commit/src/string/memmem.c?id=c86f2974e2acd330be2d587173dd4dd56db82e22>
> Link: <https://android.googlesource.com/platform/bionic/+/android-9.0.0_r3/libc/bionic/memmem.cpp>
> Link: <https://www.freebsd.org/cgi/man.cgi?query=memmem&sektion=3&format=html>
> Link: <https://man.openbsd.org/memmem.3>
> Link: <https://anonhg.netbsd.org/src/diff/96a37d536271/common/lib/libc/string/memmem.c>
> Suggested-by: Alejandro Colomar <alx@kernel.org>
> Signed-off-by: Andrew Clayton <andrew@digital-domain.net>
> ---
> 
>   v2:
>    - Remove references to bionic and macOS from the man page
>    - Convert & to and
>    - Use Oxford comma
>    - Add dates where known to the commit message
>    - Use present tense for the subject line

Oh, thanks for this one!  I hadn't realized.  :P

> 
>   man3/memmem.3 | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/man3/memmem.3 b/man3/memmem.3
> index 134dffab0..cb0d3e195 100644
> --- a/man3/memmem.3
> +++ b/man3/memmem.3
> @@ -58,7 +58,9 @@ T}	Thread safety	MT-Safe
>   .sp 1
>   .SH STANDARDS
>   This function is not specified in POSIX.1,
> -but is present on a number of other systems.
> +but is present on a number of other systems,
> +including: musl libc 0.9.7; FreeBSD 6.0, OpenBSD 5.4,
> +NetBSD, and Illumos.

I've been thinking about the line breaks.  I'm not sure how I'd split them, but 
I'm not happy with the current suggestion.

Please see man-pages(7) about semantic newlines, and see if you come up with 
something nicer.

man-pages(7):
    Use semantic newlines
        In  the  source of a manual page, new sentences should be
        started on new lines, long sentences should be split into
        lines at clause breaks (commas, semicolons,  colons,  and
        so on), and long clauses should be split at phrase bound‐
        aries.   This  convention,  sometimes  known as "semantic
        newlines", makes it easier to see the effect of  patches,
        which often operate at the level of individual sentences,
        clauses, or phrases.

<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=6ff6f43d68164f99a8c3fb66f4525d145571310c>

Cheers,

Alex

>   .SH BUGS
>   .\" This function was broken in Linux libraries up to and including libc 5.0.9;
>   .\" there the

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

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

Re: [PATCH v2] memmem.3: Add list of known systems where this is available

[Andrew Clayton]

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

On Fri, 11 Nov 2022 00:59:59 +0100
Alejandro Colomar <alx.manpages@gmail.com> wrote:

> > +but is present on a number of other systems,
> > +including: musl libc 0.9.7; FreeBSD 6.0, OpenBSD 5.4,
> > +NetBSD, and Illumos.  
> 
> I've been thinking about the line breaks.  I'm not sure how I'd split them, but 
> I'm not happy with the current suggestion.
> 
> Please see man-pages(7) about semantic newlines, and see if you come up with 
> something nicer.
> 
> man-pages(7):
>     Use semantic newlines
>         In  the  source of a manual page, new sentences should be
>         started on new lines, long sentences should be split into
>         lines at clause breaks (commas, semicolons,  colons,  and
>         so on), and long clauses should be split at phrase bound‐
>         aries.   This  convention,  sometimes  known as "semantic
>         newlines", makes it easier to see the effect of  patches,
>         which often operate at the level of individual sentences,
>         clauses, or phrases.

I guess the best thing then is to just break it on the semi-colon.

Andrew

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

Re: [PATCH v2] memmem.3: Add list of known systems where this is available

[Alejandro Colomar]

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



On 11/11/22 01:04, Andrew Clayton wrote:
> On Fri, 11 Nov 2022 00:59:59 +0100
> Alejandro Colomar <alx.manpages@gmail.com> wrote:
> 
>>> +but is present on a number of other systems,
>>> +including: musl libc 0.9.7; FreeBSD 6.0, OpenBSD 5.4,
>>> +NetBSD, and Illumos.
>>
>> I've been thinking about the line breaks.  I'm not sure how I'd split them, but
>> I'm not happy with the current suggestion.
>>
>> Please see man-pages(7) about semantic newlines, and see if you come up with
>> something nicer.
>>
>> man-pages(7):
>>      Use semantic newlines
>>          In  the  source of a manual page, new sentences should be
>>          started on new lines, long sentences should be split into
>>          lines at clause breaks (commas, semicolons,  colons,  and
>>          so on), and long clauses should be split at phrase bound‐
>>          aries.   This  convention,  sometimes  known as "semantic
>>          newlines", makes it easier to see the effect of  patches,
>>          which often operate at the level of individual sentences,
>>          clauses, or phrases.
> 
> I guess the best thing then is to just break it on the semi-colon.

Yeah, either semicolon or ':'.

> 
> Andrew

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

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

Re: [PATCH v2] memmem.3: Add list of known systems where this is available

[Andrew Clayton]

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

On Fri, 11 Nov 2022 01:05:18 +0100
Alejandro Colomar <alx.manpages@gmail.com> wrote:

> >>> +but is present on a number of other systems,
> >>> +including: musl libc 0.9.7; FreeBSD 6.0, OpenBSD 5.4,
> >>> +NetBSD, and Illumos.  

[...]

> > I guess the best thing then is to just break it on the semi-colon.  
> 
> Yeah, either semicolon or ':'.

Or maybe both?

Andrew

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

Re: [PATCH v2] memmem.3: Add list of known systems where this is available

[Alejandro Colomar]

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

On 11/11/22 01:20, Andrew Clayton wrote:
> On Fri, 11 Nov 2022 01:05:18 +0100
> Alejandro Colomar <alx.manpages@gmail.com> wrote:
> 
>>>>> +but is present on a number of other systems,
>>>>> +including: musl libc 0.9.7; FreeBSD 6.0, OpenBSD 5.4,
>>>>> +NetBSD, and Illumos.
> 
> [...]
> 
>>> I guess the best thing then is to just break it on the semi-colon.
>>
>> Yeah, either semicolon or ':'.
> 
> Or maybe both?

Definitely it is a very valid option.  I was hesitant, because it could be a bit 
of overkill, but if it makes sense to you, go ahead.

Cheers,

Alex

> 
> Andrew

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

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

[PATCH v3] memmem.3: Add list of known systems where this is available

[Andrew Clayton]

While looking at which systems provide memmem(3) I have been able to
discern the following:

  musl libc since v0.9.7 (2012)
  bionic since Android 9 (2018)

  FreeBSD since 6.0 (2005)
  OpenBSD since 5.4 (2013)
  NetBSD
  macOS
  Illumos

For macOS and Illumos I checked the memmem(3) man page on those systems.
For the rest there are links below to on-line man pages or commit logs.

Where I could determine what version memmem(3) was introduced, I've
noted that in the man page.

Link: <http://git.musl-libc.org/cgit/musl/commit/src/string/memmem.c?id=c86f2974e2acd330be2d587173dd4dd56db82e22>
Link: <https://android.googlesource.com/platform/bionic/+/android-9.0.0_r3/libc/bionic/memmem.cpp>
Link: <https://www.freebsd.org/cgi/man.cgi?query=memmem&sektion=3&format=html>
Link: <https://man.openbsd.org/memmem.3>
Link: <https://anonhg.netbsd.org/src/diff/96a37d536271/common/lib/libc/string/memmem.c>
Suggested-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <andrew@digital-domain.net>
---

 v3:
  - Split the platform list on ':' and ';'

 v2:
  - Remove references to bionic and macOS from the man page
  - Convert & to and
  - Use Oxford comma
  - Add dates where known to the commit message
  - Use present tense for the subject line

 man3/memmem.3 | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/man3/memmem.3 b/man3/memmem.3
index 134dffab0..4a4a885fc 100644
--- a/man3/memmem.3
+++ b/man3/memmem.3
@@ -58,7 +58,10 @@ T}	Thread safety	MT-Safe
 .sp 1
 .SH STANDARDS
 This function is not specified in POSIX.1,
-but is present on a number of other systems.
+but is present on a number of other systems,
+including:
+musl libc 0.9.7;
+FreeBSD 6.0, OpenBSD 5.4, NetBSD, and Illumos.
 .SH BUGS
 .\" This function was broken in Linux libraries up to and including libc 5.0.9;
 .\" there the
-- 
2.38.1

Re: [PATCH v3] memmem.3: Add list of known systems where this is available

[Alejandro Colomar]

Hi Andrew!

On 11/11/22 02:27, Andrew Clayton wrote:
> While looking at which systems provide memmem(3) I have been able to
> discern the following:
> 
>    musl libc since v0.9.7 (2012)
>    bionic since Android 9 (2018)
> 
>    FreeBSD since 6.0 (2005)
>    OpenBSD since 5.4 (2013)
>    NetBSD
>    macOS
>    Illumos
> 
> For macOS and Illumos I checked the memmem(3) man page on those systems.
> For the rest there are links below to on-line man pages or commit logs.
> 
> Where I could determine what version memmem(3) was introduced, I've
> noted that in the man page.
> 
> Link: <http://git.musl-libc.org/cgit/musl/commit/src/string/memmem.c?id=c86f2974e2acd330be2d587173dd4dd56db82e22>
> Link: <https://android.googlesource.com/platform/bionic/+/android-9.0.0_r3/libc/bionic/memmem.cpp>
> Link: <https://www.freebsd.org/cgi/man.cgi?query=memmem&sektion=3&format=html>
> Link: <https://man.openbsd.org/memmem.3>
> Link: <https://anonhg.netbsd.org/src/diff/96a37d536271/common/lib/libc/string/memmem.c>
> Suggested-by: Alejandro Colomar <alx@kernel.org>
> Signed-off-by: Andrew Clayton <andrew@digital-domain.net>

Patch applied.  Thanks!

Cheers,

Alex

> ---
> 
>   v3:
>    - Split the platform list on ':' and ';'
> 
>   v2:
>    - Remove references to bionic and macOS from the man page
>    - Convert & to and
>    - Use Oxford comma
>    - Add dates where known to the commit message
>    - Use present tense for the subject line
> 
>   man3/memmem.3 | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/man3/memmem.3 b/man3/memmem.3
> index 134dffab0..4a4a885fc 100644
> --- a/man3/memmem.3
> +++ b/man3/memmem.3
> @@ -58,7 +58,10 @@ T}	Thread safety	MT-Safe
>   .sp 1
>   .SH STANDARDS
>   This function is not specified in POSIX.1,
> -but is present on a number of other systems.
> +but is present on a number of other systems,
> +including:
> +musl libc 0.9.7;
> +FreeBSD 6.0, OpenBSD 5.4, NetBSD, and Illumos.
>   .SH BUGS
>   .\" This function was broken in Linux libraries up to and including libc 5.0.9;
>   .\" there the

Re: [PATCH v3] memmem.3: Add list of known systems where this is available

[Brian Inglis]

On Fri, 11 Nov 2022 01:27:24 +0000, Andrew Clayton wrote:
> While looking at which systems provide memmem(3) I have been able to
> discern the following:
> 
>   musl libc since v0.9.7 (2012)
>   bionic since Android 9 (2018)
> 
>   FreeBSD since 6.0 (2005)
>   OpenBSD since 5.4 (2013)
>   NetBSD
>   macOS
>   Illumos

FYI:

Newlib added on 2008-01-12
https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=40617efc8b9309006af1f0c72425fc4a404f40d4

tagged as 1.16 2008-09-04
https://sourceware.org/git/?p=newlib-cygwin.git&a=search&h=refs%2Ftags%2Fnewlib-1_16_0&st=commit&s=memmem

Cygwin added on 2005-11-08 replaced by newlib 2008-01-15 untagged releases 
between about 1.4 and 1.6

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

Re: [PATCH] memmem.3: Added list of known systems where this is available

[Guillem Jover]

Hi!

On Thu, 2022-11-10 at 12:36:47 +0100, Alejandro Colomar wrote:
> On 11/10/22 01:13, Andrew Clayton wrote:
> > While looking at which systems provide memmem(3) I have been able to
> > discern the following:
> > 
> >    musl libc since v0.9.7
> >    bionic since Android 9
> > 
> >    FreeBSD since 6.0
> >    OpenBSD since 5.4
> >    NetBSD
> >    macOS
> >    Illumos
 
> > For macOS and Illumos I checked the memmem(3) man page on those systems.
> > For the rest there are links below to on-line man pages or commit logs.

> > +FreeBSD 6.0, OpenBSD 5.4, NetBSD, macOS & Illumos.
 
> For the commit message, it's interesting to note macOS and Bionic, for
> speleology purposes.  However, I'm opposed to adding them to the page itself
> because of the following:
> 
> -  macOS is not free software.  I refuse to reference nonfree software on
> this project.

I understand where you are coming from, and from a full system PoV,
it's very true that macOS is non-free. But the lower layers of its
stack are free software (at least according to the FSF and OSI), such
as its kernel (Darwin), or its libc (where memmem() is implemented):

  https://opensource.apple.com/source/Libc/Libc-1439.40.11/

among others.

Similar with Solaris and Illumos (but with the CDDL, MIT, BSD), AFAIUI.

> -  Android is not a real Unix system, in that you can't even program in C in
> there, unless you're Google or have hacked your system.  It's not friendly
> to us programmers, so we don't need to be friendly to it.  I don't want to
> be cluttering the pages with information that is irrelevant to normal users.

I'm assuming bionic is being used in some of the Android free
alternatives too, but then I'm not sure how usable for programming those
are either. And, well musl libc is not a real Unix system you can program
against either. :)

In any case I also find it useful to have this kind of portability
information when deciding what to use in code. But can understand the
reluctance to include such references, at least if thought out as the
entire system. Perhaps thinking about these merely at their kernel or
libc level would make including information about some of them more
palatable, given that standalone they are free software? So perhaps
an option is to instead refer to their specific components, say
"bionic libc X.Y", "Apple Libc M.N.O" or similar.

Thanks,
Guillem

Re: [PATCH] memmem.3: Added list of known systems where this is available

[Stefan Puiu]

Hi,

On Wed, Nov 23, 2022 at 1:39 AM Guillem Jover <guillem@hadrons.org> wrote:
>
> Hi!
>
> On Thu, 2022-11-10 at 12:36:47 +0100, Alejandro Colomar wrote:
> > On 11/10/22 01:13, Andrew Clayton wrote:
> > > While looking at which systems provide memmem(3) I have been able to
> > > discern the following:
> > >
> > >    musl libc since v0.9.7
> > >    bionic since Android 9
> > >
> > >    FreeBSD since 6.0
> > >    OpenBSD since 5.4
> > >    NetBSD
> > >    macOS
> > >    Illumos
>
> > > For macOS and Illumos I checked the memmem(3) man page on those systems.
> > > For the rest there are links below to on-line man pages or commit logs.
>
> > > +FreeBSD 6.0, OpenBSD 5.4, NetBSD, macOS & Illumos.
>
> > For the commit message, it's interesting to note macOS and Bionic, for
> > speleology purposes.  However, I'm opposed to adding them to the page itself
> > because of the following:
> >
> > -  macOS is not free software.  I refuse to reference nonfree software on
> > this project.
>
> I understand where you are coming from, and from a full system PoV,
> it's very true that macOS is non-free. But the lower layers of its
> stack are free software (at least according to the FSF and OSI), such
> as its kernel (Darwin), or its libc (where memmem() is implemented):
>
>   https://opensource.apple.com/source/Libc/Libc-1439.40.11/
>
> among others.
>
> Similar with Solaris and Illumos (but with the CDDL, MIT, BSD), AFAIUI.
>
> > -  Android is not a real Unix system, in that you can't even program in C in
> > there, unless you're Google or have hacked your system.  It's not friendly
> > to us programmers, so we don't need to be friendly to it.  I don't want to
> > be cluttering the pages with information that is irrelevant to normal users.
>
> I'm assuming bionic is being used in some of the Android free
> alternatives too, but then I'm not sure how usable for programming those
> are either. And, well musl libc is not a real Unix system you can program
> against either. :)
>
> In any case I also find it useful to have this kind of portability
> information when deciding what to use in code. But can understand the
> reluctance to include such references, at least if thought out as the
> entire system. Perhaps thinking about these merely at their kernel or
> libc level would make including information about some of them more
> palatable, given that standalone they are free software? So perhaps
> an option is to instead refer to their specific components, say
> "bionic libc X.Y", "Apple Libc M.N.O" or similar.

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.

For musl and other libcs, I think the man pages already document some
instances where their behavior diverges from glibc.

Just my 2c,
Stefan.

>
> Thanks,
> Guillem

Re: [PATCH] memmem.3: Added list of known systems where this is available

[Alejandro Colomar]

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

Hi all!

On 11/23/22 13:52, Stefan Puiu wrote:
> Hi,
> 
> On Wed, Nov 23, 2022 at 1:39 AM Guillem Jover <guillem@hadrons.org> wrote:
>>
>> Hi!
>>
>> On Thu, 2022-11-10 at 12:36:47 +0100, Alejandro Colomar wrote:
>>> On 11/10/22 01:13, Andrew Clayton wrote:
>>>> While looking at which systems provide memmem(3) I have been able to
>>>> discern the following:
>>>>
>>>>     musl libc since v0.9.7
>>>>     bionic since Android 9
>>>>
>>>>     FreeBSD since 6.0
>>>>     OpenBSD since 5.4
>>>>     NetBSD
>>>>     macOS
>>>>     Illumos
>>
>>>> For macOS and Illumos I checked the memmem(3) man page on those systems.
>>>> For the rest there are links below to on-line man pages or commit logs.
>>
>>>> +FreeBSD 6.0, OpenBSD 5.4, NetBSD, macOS & Illumos.
>>
>>> For the commit message, it's interesting to note macOS and Bionic, for
>>> speleology purposes.  However, I'm opposed to adding them to the page itself
>>> because of the following:
>>>
>>> -  macOS is not free software.  I refuse to reference nonfree software on
>>> this project.
>>
>> I understand where you are coming from,

:-)

>> and from a full system PoV,
>> it's very true that macOS is non-free. But the lower layers of its
>> stack are free software (at least according to the FSF and OSI), such
>> as its kernel (Darwin), or its libc (where memmem() is implemented):
>>
>>    https://opensource.apple.com/source/Libc/Libc-1439.40.11/
>>
>> among others.

Hmmm.  Fair enough.

>>
>> Similar with Solaris and Illumos (but with the CDDL, MIT, BSD), AFAIUI.
>>
>>> -  Android is not a real Unix system, in that you can't even program in C in
>>> there, unless you're Google or have hacked your system.  It's not friendly
>>> to us programmers, so we don't need to be friendly to it.  I don't want to
>>> be cluttering the pages with information that is irrelevant to normal users.
>>
>> I'm assuming bionic is being used in some of the Android free
>> alternatives too, but then I'm not sure how usable for programming those
>> are either. And, well musl libc is not a real Unix system you can program
>> against either. :)

The difference is only that bionic is not in use in useful systems (AFAIK).  :)

So we have to do some decission here (and also about newlib, as reported by Brian).

>>
>> In any case I also find it useful to have this kind of portability
>> information when deciding what to use in code.

And I must admit it's also useful to me (this all started because Andrew and I 
had to use memmem(3) at a project where macOS compatibility is relevant --not 
critical, but relevant--).

>> But can understand the
>> reluctance to include such references, at least if thought out as the
>> entire system. Perhaps thinking about these merely at their kernel or
>> libc level would make including information about some of them more
>> palatable, given that standalone they are free software? So perhaps
>> an option is to instead refer to their specific components, say
>> "bionic libc X.Y", "Apple Libc M.N.O" or similar.

Yep, that's more palatable :)

I think I'd accept a patch stating Apple Libc version for memmem(3).

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

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.

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/>

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

Re: [musl] Re: [PATCH] memmem.3: Added list of known systems where this is available

[Jeffrey Walton]

On Wed, Nov 23, 2022 at 9:29 AM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
>  ...
> >> In any case I also find it useful to have this kind of portability
> >> information when deciding what to use in code.
>
> And I must admit it's also useful to me (this all started because Andrew and I
> had to use memmem(3) at a project where macOS compatibility is relevant --not
> critical, but relevant--).

If you are a die-hard free software person using GNU gear, then Gnulib
provides memmem. There's no need to worry about availability or
portability courtesy of Gnulib. See
https://www.gnu.org/software/gnulib/manual/html_node/memmem.html .

Jeff

Re: [musl] Re: [PATCH] memmem.3: Added list of known systems where this is available

[Alejandro Colomar]

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

Hi Jeffrey,

On 11/23/22 15:55, Jeffrey Walton wrote:
> On Wed, Nov 23, 2022 at 9:29 AM Alejandro Colomar
> <alx.manpages@gmail.com> wrote:
>>   ...
>>>> In any case I also find it useful to have this kind of portability
>>>> information when deciding what to use in code.
>>
>> And I must admit it's also useful to me (this all started because Andrew and I
>> had to use memmem(3) at a project where macOS compatibility is relevant --not
>> critical, but relevant--).
> 
> If you are a die-hard free software person using GNU gear, then Gnulib
> provides memmem. There's no need to worry about availability or
> portability courtesy of Gnulib. See
> https://www.gnu.org/software/gnulib/manual/html_node/memmem.html .

Thanks!

However, for this project I was talking about, it's not an option; such a 
dependency would not be accepted.

BTW, personally, I always found very confusing the usage of Gnulib compared to 
normal packaged libraries.  Maybe it's just me; don't know.  It also forces you 
to use GNU autotools, which I don't like at all.  I prefer the approach of 
libbsd, which just provides a couple of pc(5) files to allow using as a library 
or as an overlay over the system libc, and after that you're fine with whatever 
build system you prefer.  I know it has some issues, such as 
<https://gitlab.freedesktop.org/libbsd/libbsd/-/issues/5>, which may be the 
reason Gnulib works that way, I don't know.

Guillem, do you think that issue with libbsd and <queue.h> can be fixed?  Or is 
it an inherent issue of the way the overlay works?  Maybe it would be 
interesting to fix it, as a proof of concept that something like Gnulib could be 
implemented in that way.

Cheers,

Alex

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

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

Re: [PATCH] memmem.3: Added list of known systems where this is available

[Stefan Puiu]

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/>

Re: [PATCH] memmem.3: Added list of known systems where this is available

[Alejandro Colomar]

[-- 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 --]

Re: [PATCH] memmem.3: Added list of known systems where this is available

[Brian Inglis]

On 2022-11-23 06:16, Alejandro Colomar wrote:
> On 11/23/22 13:52, Stefan Puiu wrote:
>> On Wed, Nov 23, 2022 at 1:39 AM Guillem Jover wrote:
>>> On Thu, 2022-11-10 at 12:36:47 +0100, Alejandro Colomar wrote:
>>>> On 11/10/22 01:13, Andrew Clayton wrote:
>>>>> While looking at which systems provide memmem(3) I have been able to
>>>>> discern the following:
>>>>>     musl libc since v0.9.7
>>>>>     bionic since Android 9
>>>>>     FreeBSD since 6.0
>>>>>     OpenBSD since 5.4
>>>>>     NetBSD
>>>>>     macOS
>>>>>     Illumos
>>>>> For macOS and Illumos I checked the memmem(3) man page on those systems.
>>>>> For the rest there are links below to on-line man pages or commit logs.
>>>>> +FreeBSD 6.0, OpenBSD 5.4, NetBSD, macOS & Illumos.
>>>> For the commit message, it's interesting to note macOS and Bionic, for
>>>> speleology purposes.  However, I'm opposed to adding them to the page itself
>>>> because of the following:
>>>> -  macOS is not free software.  I refuse to reference nonfree software on
>>>> this project.
>>> I understand where you are coming from,
> :-)
>>> and from a full system PoV,
>>> it's very true that macOS is non-free. But the lower layers of its
>>> stack are free software (at least according to the FSF and OSI), such
>>> as its kernel (Darwin), or its libc (where memmem() is implemented):
>>>    https://opensource.apple.com/source/Libc/Libc-1439.40.11/
>>> among others.
> Hmmm.  Fair enough.
>>> Similar with Solaris and Illumos (but with the CDDL, MIT, BSD), AFAIUI.
>>>> - Android is not a real Unix system, in that you can't even program in C in
>>>> there, unless you're Google or have hacked your system.  It's not friendly
>>>> to us programmers, so we don't need to be friendly to it. I don't want to
>>>> be cluttering the pages with information that is irrelevant to normal users.
>>> I'm assuming bionic is being used in some of the Android free
>>> alternatives too, but then I'm not sure how usable for programming those
>>> are either. And, well musl libc is not a real Unix system you can program
>>> against either. :)
> The difference is only that bionic is not in use in useful systems (AFAIK).  :)
> So we have to do some decision here (and also about newlib, as reported by Brian).
>>> In any case I also find it useful to have this kind of portability
>>> information when deciding what to use in code.
> And I must admit it's also useful to me (this all started because Andrew and I 
> had to use memmem(3) at a project where macOS compatibility is relevant --not 
> critical, but relevant--).
>>> But can understand the
>>> reluctance to include such references, at least if thought out as the
>>> entire system. Perhaps thinking about these merely at their kernel or
>>> libc level would make including information about some of them more
>>> palatable, given that standalone they are free software? So perhaps
>>> an option is to instead refer to their specific components, say
>>> "bionic libc X.Y", "Apple Libc M.N.O" or similar.
> Yep, that's more palatable :)
> I think I'd accept a patch stating Apple Libc version for memmem(3).
>> 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.
> 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.
> 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?)

Newlib is a Sourceware supported project originally by Cygnus then RedHat;
- now licensed under BSD, based partially on some BSD sources;
- used mainly for embedded systems and OSes, including those supported by 
processor, system, and GCC tool chain vendors, and by manufacturers in their 
products, some of whom contribute back to the project;
- significant libre OS RTEMS, which itself supports many embedded targets, is 
used with space qualified hardware on ESA and NASA Mars orbiter projects, and 
replaced glibc in NaCl a decade ago;
- info and man pages are generated from function source embedded comments using 
makedoc/DocBook.

See below and the relevant .org sites:
	https://en.wikipedia.org/wiki/Newlib
- that page also provide links to summary info on other libc implementations;
	https://en.wikipedia.org/wiki/RTEMS

Newlib is included in Phil Zimmerman's regular comparison of all major C math 
library implementations single thru quad precision functions:
	https://members.loria.fr/PZimmermann/papers/accuracy.pdf
which compares GNU MPFR (to which PZ contributes) results to those from GNU 
libc, Intel, AMD LibM, Newlib, OpenLibm, Musl, Darwin, LLVM libc, CUDA, and ROCm 
math libraries.

Newlib is also used by Sourceware supported libre kernel emulator project Cygwin 
originally by Cygnus then RedHat;
- works like a Unix distro hosted on and fully interoperable (unlike WSL so far) 
with Windows;
- originally aiming for POSIX and feasible Solaris, now Linux, compatibility;
- supports over 12k BSD, GNU, and other libre libraries and packages;
- on both 64 and, until recently, 32 bit systems;
- appears to be used by manufacturers and vendors to provide embedded 
development on Windows;
- support native Windows cross-compiler, binutils platform, and code base for 
parts of the Mingw/32/64, Msys/2, and Wine projects, and others like Git for 
Windows.

Cygwin provides its own utility, emulation library, newlib libc plus all 
packages' GNU info and man pages, man-pages-posix, and also man-pages(-linux) 
packages under man-db.
Compatibility with everything above kernel syscalls and data structures for 
porting packages is the project goal, so process fork/exec, multithreading, and 
multiprocessor scheduling are all supported using standard interfaces.

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry