[PATCH] diff portability fixes

[Dan Fandrich]

On Mon, Feb 08, 2010 at 02:05:20PM -0600, Rob Landley wrote:
> 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.

That's all fascinating, but irrelevant if you've been tasked to upgrade
BusyBox on a decade-old deployed system that was necessarily built using
a pre-C99 toolchain.  Since BusyBox targets embedded systems that aren't
able to bump compiler versions as easily as a cutting-edge desktop distro
can, I'm surprised to hear this kind of attitude about using the latest
compiler features.  The fact that the BusyBox README even has a
portability section shows that at least lip service is being paid to
portability issues, but this goes directly against the cause of portability.

Of course, you and the other BusyBox developers are free to say SOL to such
users and thereby reduce the community population.  On other embedded projects
I've worked on, we bend over backwards to try to accomodate such users,
but that, of course, has costs as well.

> 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'm fixing problems that I've encountered, rather than theoretical problems
that I haven't encountered.  As you say, some parts of C99 have been 
implemented in tool chains even before the standard was finalized and are more
widely available.

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

Maybe you didn't read that right--I'm NOT submitting those, despite the
improvement in portability they would engender.

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

I would welcome more explicit mention of these issues, but I'd like to see
them in the git source since they're more developer issues.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved