Headers including headers and precompilation

[Rob Landley]

On Friday 31 March 2006 4:52 pm, Rich Felker wrote:
> On Fri, Mar 31, 2006 at 03:06:25PM -0500, Rob Landley wrote:
> > > > For what it's worth, I vote for the way I picked up and liked after
> > > > programming
> > > > with Cocoa for a while.  Have a single local header that includes all
> > > > system includes used anywhere in the program, or at least in our case
> > > > all SUSv3 and linux ones.  The main advantage is less maintenance. 
> > > > But it also avoids the redundancy when local headers include a system
> > > > header and so does the main.c file.
> > >
> > > IMO this is very bad practice. Not only does it hide what the real
> > > dependencies are,
> >
> > And being permanently unable to #include headers that you can build
> > without _doesn't_?  Because that's the result of a policy of #include
> > extra headers even if we don't need them...
>
> Huh? I failed to parse that sentence and don't see how it's related to
> what I said...

Sorry, I meant being permanently unable to remove #includes that you can build 
without.

> > > but it also brings lots of unnecessary symbols and
> > > definitions into the namespace of each file, increasing memory
> > > requirements to compile, decreasing speed, and possibly causing
> > > conflicts with names due to inclusion of unexpected headers.
> >
> > Is this a real problem you've actually seen in busybox, or are you
> > proposing fixing something that isn't actually broken?
>
> What's broken in busybox is that it makes lots of assumptions about
> the system libc.

Various people are trying to fix this, using real test environments to see 
what assumptions actually break.

> I've been trying to clean this up by removing the 
> assumptions that nonstandard extensions _are_ present, but another
> problem is the assumption that nonstandard extensions are _not_
> present. I suspect this will show itself increasingly when BB is
> ported to more systems.

Good for you.  I tend to like to be shown a problem before somebody claims 
they've solved it.

> > > For example: in another project I work on, we use the name open() as a
> > > static, module-internal symbol for many modules
> >
> > Anybody who locally redefines a POSIX function deserves what they get.
>
> They deserve to have it work with no problem since POSIX _requires_ it
> to work unless you include the offending header.

Busybox does not.  There exists plenty of code that does not work with busybox 
and never will.  This is unlikely to change short of nuclear war.

> > > and export it via a
> > > struct full of function pointers. If suddenly random headers were
> > > including fcntl.h, this would obviously break.
> >
> > I had a function named "throw()" once.  It wrote directly to dos video
> > memory, much faster than printf() going through the BIOS back on my
> > trusty 386dx33. When I moved from Borland C to Borland C++, it broke
> > because throw was now a keyword.  I renamed the function.
>
> C++ is not C. I intentionally use struct members named "class" and
> "near" and such in my C code to hilight certain notoriously broken
> compilers.

My lack of caring continues to be deep and profound.

> > > but there are much more subtle cases of the same thing.
> >
> > We are not preparing busybox to accept bad code in the future.  I would
> > be _thrilled_ to break the above code, as quickly as possible, so that
> > potential problems like that are found and fixed.
>
> What about something like:
> static int index( /* ... */ );
>
> This is a totally sane reasonable function name but might break if a
> header that defines legacy BSD functions is included.

When problems present themselves, I worry about it then.

> Other names that are likely to appear in code that has no knowledge of
> SUS legacy crap: getcontext(), makecontext(), ..

You know what?  I've officially stopped caring about your concern here.  I'm 
sorry, but I have.  It sounds like you have lots of code that is not a 
candidate for inclusion in busybox.  The solution is not to include it in 
busybox.

I'm sorry, you've managed to hit my "SCREW IT" threshold.

> And names that are NOT in SUSv3 but used on various legacy systems:
> getpass(), ...

I don't care.

> The whole reason POSIX/SUSv3 require header isolation rather than
> allowing one big header that defines everything is so that developers
> don't have to know every obscure, useless library function and avoid
> namespace clashes when writing code that is _internal_ to a single
> translation unit.

In busybox, you do.  Deal with it.

> This saves a lot of effort looking up and avoiding 
> conflicting names and allows the most natural, simple names to be used
> for many module-internal symbols.

Not my problem.

> > > It's not the responsibility of an author to make sure
> > > their static symbols do not conflict with unrelated system headers
> > > which they do not use.
> >
> > And it's not the responsibility of busybox to allow people to bolt utter
> > crap onto it.
>
> Agree.
>
> But I don't think it's too much to ask for correct explicit header
> dependencies rather than a sloppy catch-all header, even if you
> disagree with my above reasoning.

You have yet to show a single real world problem anyone has actually 
encountered, and you have yet to provide a single patch.  You've squandered 
the opportunity to talk about what headers are #included from libbb.h now and 
whether any of those should be removed as "just plain stupid" (the passwd 
stuff I'm actually working on removing anyway as part of the big passwd.c 
cleanup, and now I'm curious what netdb.h is for anyway).  But I think 
#include <stdio.h> is pretty darn defensible, and anything you can break by 
#including <stdio.h> is so broken I don't want it anywhere NEAR busybox, so 
your blanket statement of absolutism is counterproductive.

You've also used up my patience for arguing about it, without ever proposing a 
single concrete incremental change that would move you towards something 
you're more comfortable with.  If you'd said "why don't we remove netdb.h 
from libbb.h" that would at least have given us something specific we could 
have discussed the merits of.  But at this point?  I don't want to hear it 
anymore.

Rob
-- 
Never bet against the cheap plastic solution.