Headers including headers and precompilation

[Rich Felker]

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

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

> I'm all for simplification and untangling.  I'm not for statements of policy 
> that have nothing nothing to do with current problems, nor are presented in 
> the context of a proposed patch series with a clear result.

That's understandable. In any case this is all an aside.

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

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

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

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

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

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

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

Rich