getting Android's bionic C library back in sync with upstream

[enh <enh%google.com@localhost>]

hi, my name's Elliott, and i'm a C library maintainer.

as you may be aware, Android's C library "bionic" is a hybrid of code
from different sources --- there's stuff like the pthreads
implementation that's home grown, but there's a lot of FreeBSD,
NetBSD, and OpenBSD code in there too. NetBSD files aren't from a
single NetBSD release; hell, they're not even necessarily from _any_
release. i found a bug in getcwd (iirc) that had been fixed upstream
in like 1996, but we had some random old version of that file. (and
similar for the other BSD flavors.)

i'd like to get bionic to a point where we have one upstream (that is,
i'd like to get all my upstream code from FreeBSD _or_ NetBSD _or_
OpenBSD, not a mixture), and where we can easily track that upstream.
so i have a few questions:

* is this an appropriate mailing list for my questions? if not, please
stop reading and (if you know) tell me who i should bother instead.

* do the different BSD flavors have a shared upstream C library? it
looks like they're divergent, so i'm guessing no.

* is libm a special case? do you guys get that from some other
upstream that i should be pulling from directly?

* if i'm choosing just one flavor, would NetBSD be a good flavor for
me to go with? i realize you're likely to be biased, but if you can
think of some reason why i should be looking at one of the other BSDs
instead, please let me know!

* who speaks for the BSD C library community? everyone knows the glibc
names, but i'm afraid i'm ignorant when it comes to BSD.

* when i have bugs that aren't fixed upstream, where's the best place
for me to submit patches? there's a getopt_long bug, for example,
that's been reported to me that appears to be broken upstream too
(https://android-review.googlesource.com/#/c/37620/). for obvious
reasons, i'd prefer to fix stuff upstream and cherry-pick the fix into
bionic afterwards.

* how do you feel about GNU extensions? one problem i have is that i'm
often faced with code ported from Linux that expects to run on glibc.
so when glibc's freeaddrinfo(3) accepts and ignores NULL like most of
the other free-like functions do, it causes trouble for me that the
BSD freeaddrinfo(3) blows up in this case. would you accept patches
for GNU extensions, or is that anathema to you?

* how do you feel about #ifdef ANDROID and/or #ifdef __linux__? (i
realize this might sound crazy, but you _are_ known for your focus on
portability!) sometimes i "fork" a file for no good reason other than
it refers to something linux doesn't have. for example, in
https://android-review.googlesource.com/#/c/37804/1 i had to add #ifs
to getnameinfo.c because linux doesn't have AF_LINK. other than that,
the NetBSD getnameinfo works fine on linux. obviously my life would be
easier if i could get my linux portability stuff upstream. (i realize
there might be a continuum where something like that change might be
acceptable but something really invasive might not. for now i'm just
interested in principle. so i guess a related question would be
whether you'd consider patches that moved non-portable stuff into
separate files?)

i think that's about it for now. thanks!

 -enh