tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

(I broadly concur with the other comments and won't repeat them.)

enh <> writes:

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

This is the trickiest question you asked.  Generally NetBSD has a pretty
strong focus on POSIX compliance.  If there are extensions that are well
though out and in widespread use, those are typically adopted.   Adding
less well thought out extensions to enable non-portable code is likely
to be more controversial.

A perhaps relevant anecdote is that a lot of the pthread functions are
specified to have undefined behavior in error cases (unlocking unlocked
mutex, locking an uninitialized mutex, etc.).  For a while NetBSD's
default behavior was to abort in those cases; this behavior is standards
compliant and took the view that such calls were buggy and a clue to
more underlying issues.  But there was so much code that did this
(mozilla, at least, IIRC) and so little progress in those upstreams
fixing their code that the default was changed, with some angst.

Another issue is == in bash (test).  POSIX says =, and it's been = for
35 years.  There's no good reason for bash to have ever allowed ==, and
it's been a source of incompatibility with posix shells.  Perhaps this
was an accomodation for people who didn't understand that sh and C are
different languages; it's hard to believe that it was a deliberate
attempt at lock-in (although it has somewhat that effect, and leads to
scripts with #!/bin/bash, which is gratuitously nonportable).  So there
I'd say the right course of action is for bash to make == deprecated and
start throwing warnings.

So I think it depends on where each extension is on the continuum of
"broadly sensible and happens to be only in glibc at the moment, and has
been submitted to POSIX for adoption" to "shouldn't have happened and
serves no useful purpose other than to encourage people to write
non-portable code".

Attachment: pgpea4rxChwww.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index