[PATCH] diff portability fixes

[Cathey, Jim]

>Is their lack of standards compliance what makes them "worthy"?

I have no idea about their standards compliance.  What makes
them worthy is whether or not they work well.  Support, debuggers
(omg gdb is the worst thing I've ever used... barely works half
the time), target code size/speed, compilation speed, lack of bugs,
etc.  Many factors, indeed.

>So you're advocating K&R then?  No function prototypes?  (They are, 
>technically, unnecessary...)

Not at all.  (I was referring to K&R formatting rules, not their
level of C compiler.)  But requiring the latest gcc, as Linux does,
isn't all that admirable either.  I'm just pointing out that BB
ought to have a different focus.  You can point to an out-of-date
header/README, but how's the code base itself doing?  Anybody
ever fed it lately to something that _wasn't_ gcc-du-jour?

Call me an old fart.  But I date from a time when portability
was taken seriously, and by portability I don't mean "we've got
both kinds, Country AND Western!"

Right now I'm in the throes of feeding one code base to
both gcc and a Green Hills compiler.  Keeping them both happy
is occasionally not trivial.  I like to do most of my trial
builds in gcc, because it is much faster on the hardware it's
running on.  But for tricky debugging I like to use GH, because
its debugger is so infinitely preferable to gdb.  NOBODY here
prefers gdb, and we're still trying to find somebody to sell us
a better Linux debugger at a reasonable price.  (Reasonable being
defined as something approximating what we paid for the non-Linux
one we've got.  Proving it's better, for us, has turned out to be
hard.)  But I digress...

I have _personal_ coding style preferences, developed over the
years because they help aid understanding in the areas _I_ particularly
care about.  I will continue to advocate them, at times, because
I believe they work well.  If a standard develops that contravenes
them, well then the standard is an ass!  :-)

-- Jim