[PATCH] diff portability fixes

[Rob Landley]

On Monday 08 February 2010 14:59:20 Dan Fandrich wrote:
> 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.

It's a balancing users vs balancing development community thing.  The needs 
of, as far as I can tell, exactly one user, vs ongoing constraints on all 
developers that can't even be clearly documented.  ("We support c99" is clear.  
"We support gcc version X" is also clear.  "Bits of your patch may or may not 
be reverted in future, there's know way to know" isn't clear, I haven't 
trouble being comfortable with that.)

All this is Denys's call, I'm just making my opinion known.  He's maintainer, 
I'm not.  Heck, if he wants to _change_ the project's official stance, citing 
precedents becomes irrelevant. :)

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

The closest the source seems to have is docs/posix_confirmance.txt, which isn't 
a policy statement.  (The style guide is a policy statement, but it dates to 
Erik Andersen's tenure and... does it really say to put inline functions in 
header files?  Um, not sure it matches the current code all that closely. :)

Policy statements like this used to be in the FAQ.  Originally the "standards" 
section was about what BusyBox implements, and the "Portability" section was 
about what busybox expects from its environment.  An "exports" vs "imports" 
thing.  That probably should have been more explicit way back when.

At the time I last updated those, I didn't have a version of C99 I could link 
to the way I could link to Posix (I.E. SUSv3 I.E. Open Group Base Standards 
Issue 6).  Nowdays if you Google for "C99" the third hit is:

  http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf

I've also clarified (at least to my satisfaction) the status of the html 
version which is up at http://busybox.net/~landley/c99-draft.html so I'm not 
worried about pointing people at it publically anymore.  If busybox officially 
wants to host its own copy for its own developers, we're probably ok with 
that.  (I'd rather link to open-std.org but they only seem to have the PDF.  
It's a slightly later draft release, but the format's harder to use.)

As the coding-style shows, if something is A) not a real approved standard 
external to this one project, B) too complicated to get in a glance, then 
reality tends to wander away from it over time.  You can be complicated as 
long as people can re-use the investment of coming up to speed on it, and you 
can be local as long as you're _simple_.  But "complicated and local" doesn't 
work very well unless you're a standard setter like the Linux kernel, which 
BusyBox isn't.  We haven't got 100 full-time develpers working on just our 
thing.  If you add up all the part-time work plus what the maintainer puts in, 
I think we generally average around the equivalent of maybe 3 full-timers.  
(Which is a lot of work, but not in linux-kernel's league.)

> >>> Dan

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