[PATCH] diff portability fixes

[Rob Landley]

On Friday 05 February 2010 21:34:12 Dan Fandrich wrote:
> On Fri, Feb 05, 2010 at 07:24:13PM -0600, Rob Landley wrote:
> > You're objecting to an 11 year old standards document that our FAQ claims
> > we adhere to.  (And I wrote that part of the FAQ back in 2006.)  This is
> > like objecting to unnecessary use of POSIX.  The mind boggles.
>
> If all the compilers in the world somehow started supporting C99 as of
> January 1, 2000, you'd have a point.

A) January 1, 2000, was over a decade ago.

B) There are pascal compilers out there, cobol compilers, basic compilers, 
java bytecode compilers.  They don't support he language BusyBox is 
implemented in, which is C99.

C) C99 was _approved_ in 1999, but drafts of the standards document had been 
circulating for years, and most of what it did was officially sanction common 
vendor extensions.

D) Fabrice Bellard's "tinycc" managed to have almost complete C99 support 
before it was abandoned.  That was more or less one guy writing a compiler 
from scratch over the course of about 3 years.

Back in 2006, our official policy was that the oldest build environment we 
supported was Red Hat 9.  (That's why http://busybox.net/downloads/qemu 
exists, to provide a Red Hat 9 build environment image we could use for 
regression testing under qemu.)  That provided full C99 support back in 2003, 
which was 7 years ago.

I _do_ have a point.

> Unfortunately, some compilers even
> today are lacking parts of C99.

If your target hasn't got a C99 compiler, it can't run things written in C99.  
(Such as the Linux kernel.)  And if your target hasn't got a cobol compiler it 
can't run things written in cobol, either,

> > I used to go with the "add enough c99 they stop thinking removing it's
> > somehow an option, let alone desirable", but it's your show...
>
> It's almost at that point now.

find . -name "*.[ch]" | xargs grep 'uint.._t' | wc -l
   1796

That wasn't in C89.

So basically, you're only removing the bits of C99 that your particular broken 
compiler doesn't support, and leaving large swaths of C99 lying around that 
Turbo C and friends wouldn't have supported back when C89 was still relevant, 
with no actual rhyme or reason behind it other than it works for you.

> I've collected a handful of patches that
> eliminate the few cases left of dynamically-sized arrays and arrays
> initialized from non-const variables, but I've sat on them because these
> are cases where readability of the code really does take a hit.

Why do you believe this is a requirement that makes any sense to impose on 
busybox developers going forwards?  Denys hasn't even bothered to regression 
test the Red Hat 9 thing since I stopped doing it.

> But I
> won't sit forever on my other patches to fix uses of non-POSIX functions
> and to allow a non-GNU linker.

Increased standards compliance is nice where it doesn't have other downsides.  
If we can switch from a gnu extension to a truly equivalent posix or C99 
version, that sounds good.  (That's why the Linux kernel redid its structure 
member initialization from the gnu syntax to the c99 syntax a few years ago.  
Once c99 shipped, they cleaned out use of gnu extensions where equivalent c99 
versions existed.)

But "increased standards compliance" and "this decade old standard that your 
project officially adopted years ago isn't good enough for me" are two very 
different positions.

Way back under Erik Andersen (maintainer up through around 2005) we were 
already targeting SUSv3 and C99, both of which were freely available on the 
web if you knew where to look.  I didn't introduce either, I just _documented_ 
them.  Since then, SUSv4 (I.E. Posix 2008) has shipped, although the changes 
don't hit us much.  We should be more explicit about it in the FAQ, but it 
_used_ to be common knowledge...

> >>> Dan

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds