(I broadly concur with the other comments and won't repeat them.) enh <enh%google.com@localhost> 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