mailing list of musl libc
 help / color / mirror / code / Atom feed
From: enh <enh@google.com>
To: musl@lists.openwall.com
Cc: alx.manpages@gmail.com
Subject: Re: [musl] [PATCH] memmem.3: Added list of known systems where this is available
Date: Wed, 30 Nov 2022 11:39:13 -0800	[thread overview]
Message-ID: <CAJgzZorSuRUMpgk3F62Aw7DPe5ytj2Syo-72W6h_=FNPeiYwVQ@mail.gmail.com> (raw)
In-Reply-To: <227F5B23-D17F-4675-B9CF-52BB5E4B7F34@shiz.me>

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

On Wed, Nov 23, 2022 at 7:33 AM Shiz <hi@shiz.me> wrote:

> Hi there,
>
> > On 23 Nov Reiwa 4, at 14:16, Alejandro Colomar <alx.manpages@gmail.com>
> wrote:
> >
> >>>> -  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).
>
> I’d like to chime in here and note that, valuations of usefulness aside,
> it *is*
> possible to develop in C against an Android device, without needing any
> hacks,
> using the NDK[1]. As someone who has occasionally worked on big codebases
> written
> in C and C++ for Android devices, I would argue there’s value to be had
> there. :-)
>

plus i think bionic is the only libc that explicitly links to man7.org as
the canonical source for documentation in its header files :-)

funnily enough, this topic ("should the man pages talk about availability
in libcs other than glibc?") came up before, and specifically for bionic
mkerrisk seemed to think it was a reasonable idea ... but i (bionic
maintainer) was less convinced. although i think that, yes, if someone's
reading that part of the page, realistically they're either interested in
macOS/iOS or Android (sorry, AIX or IRIX fans!), but specifically for those
two systems the header files already contain machine-readable availability
information via __attribute__((__available__)).

fwiw, here's an example from bionic's <unistd.h> illustrating both of those
points:

```
/**
 * [copy_file_range(2)](
https://man7.org/linux/man-pages/man2/copy_file_range.2.html) copies
 * a range of data from one file descriptor to another.
 *
 * Returns the number of bytes copied on success, and returns -1 and sets
`errno`
 * on failure.
 *
 * Available since API level 34.
 */
ssize_t copy_file_range(int __fd_in, off64_t* __off_in, int __fd_out,
off64_t* __off_out, size_t __length, unsigned int __flags)
__INTRODUCED_IN(34);
```

(if there's anything android-specific to note, we also mention that, but
there are relatively few examples of those, and it's mostly just "SELinux
means that only system processes can enable/disable swap" or whatever.)

so it wasn't clear to me whether -- unless you automated it -- there was
much value to duplicating that in the man pages? if you try to compile,
you're going to get a clear compiler error saying "you need to be targeting
OS version $whatever" anyway.

i think the real question is "aye, but will they get that far?". for my
part, i think the most value would come from cases that talk about "GNU
extension" being a bit clearer whether that's "unique to glibc" (which a
lot of people assume is what it means) or "initially in glibc, but a good
enough idea that it's effectively ubiquitous now, even if it's not in POSIX
because Solaris will never add it". and maybe the best way to clarify stuff
like that is just to explicitly state "Available on macOS since 10.4.
Available on Android since API level 23."? dunno.

if anyone _does_ want to go that route, i'd be happy to help with the "raw
data" side. (and certainly if anyone does start adding that, you'll force
me to care about maintaining it :-) )

but my biggest problem right now is that man7.org isn't being updated, and
i can't get hold of mkerrisk to try to offer him money to do it :-( (i do
hope he's okay, wherever he is!)


> > Cheers,
> >
> > Alex
>
> - Shiz
>
> [1]: https://developer.android.com/ndk

[-- Attachment #2: Type: text/html, Size: 5417 bytes --]

  reply	other threads:[~2022-11-30 19:39 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       ` [musl] " 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 [this message]
2022-12-09 20:25             ` Alejandro Colomar
2022-11-24 18:57         ` [musl] " Stefan Puiu
2022-12-11 16:30           ` 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='CAJgzZorSuRUMpgk3F62Aw7DPe5ytj2Syo-72W6h_=FNPeiYwVQ@mail.gmail.com' \
    --to=enh@google.com \
    --cc=alx.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.
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).