[PATCH] diff portability fixes

[Rob Landley]

On Wednesday 10 February 2010 10:43:13 Bernhard Reutner-Fischer wrote:
> >> Personally, I found Dan's patches to not be very intrusive, he is doing
> >> useful work, and I think he deserves the reward.
> >
> >I disagree. It makes some applets compile on C89, but they are not
> >marked as such in any way, and the user has to figure out what to
>
> The only thing that did not compile with C89 was find due to that one
> nested func. All the rest compiled fine in C89 last time i needed it.

You mean the rest compiled depending on things like inline functions, "long 
long, variadic macos, and so on to be gcc extensions rather than part of c99.

I expect attempting to compile busybox with -std=c89 would be a bit of a 
challenge.  (For one thing, we'd have to completely rewrite the config system.)

> >disable by reading compiler error messages, and he must be able to
> >deduce they are C99 incompatibilities, or else he would miss reporting
> >genuine compiler breakages or waste time reporting invalid bugs.
> >How many people out there need this anyway?
>
> busybox replaces several packages that are used in bootstrap so it's a
> worthwhile thing to attempt to be portable (if it doesn't cost size).

Hence stating up front what standards we try to adhere to.

Are you claiming that designing and manufacturing new hardware is significantly 
_easier_ than either writing a new standards-compliant compiler (which a 
number of individuals have done entirely by themselves over the years) or 
beating output for your target out of one of the existing open source ones 
(such as pcc or llvm/clang)?

What I'm trying to distinguish here is "C89 is a good standard to target" vs 
"my compiler has a bug which needs working around".

C89 has not been a good standard to target for years.  Even before C99 became 
official, lots of the new features C99 standardized were widely available as de-
facto extensions in existing compilers.  The fact you don't even _notice_ 
them, or assume they were part of C89 when they weren't, is further evidence 
that C89 is not a good standard to target anymore.

Individual platforms may need bug workarounds, but we should be clear that's 
what we're doing: working around a bug in a specific compiler.  NOT targeting 
C89 plus an enormous and indeterminate pile of extensions and pretending it's 
a standard.

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