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

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Wed, Jul 25, 2012 at 03:14:49PM -0700, enh wrote:
> * 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.

Yes.

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

No.

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

libm is derived from Sun's published code. IIRC FreeBSD is somewhat more
complete in this area, more code should be merged. One complication here
is that VAX is a non-IEEE platform.

> * 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!

Well, it is used as starting point by MINIX :)

> * when i have bugs that aren't fixed upstream, where's the best place
> for me to submit patches?

Here and/or GNATS. Post here is a good start and if there is no
reaction, filling a bug.

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

This feels wrong, at least compared to NetBSD. warnx etc append \n?

> * how do you feel about GNU extensions?

Case by case. They should be harmless and provide something useful.

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

It sounds like a much better idea to #ifdef AF_LINK in that case with a
comment what systems might lack it. I don't have a problem with such
exceptions if they don't bloat the source too much.

Joerg