Headers including headers and precompilation

[Rob Landley]

On Friday 31 March 2006 1:10 pm, Rich Felker wrote:
> On Fri, Mar 31, 2006 at 09:20:38AM -0800, Devin Bayer wrote:
> > Robert P. J. Day wrote:
> > >On Thu, 30 Mar 2006, Rob Landley wrote:
> > >>On Thursday 30 March 2006 10:33 am, Robert P. J. Day wrote:
> > >
> > >as it stands, a *lot* of the source files currently don't bother
> > >including what would normally be required system header files just
> > >because they count on getting those inclusions via "libbb.h".  so, one
> > >day, "libbb.h" is restructured to not include that header file anymore
> > >and, suddenly, lots of stuff breaks.
> > >
> > >for cleanliness, i don't think any source file should count on getting
> > >its *system* header files via a *local* header file inclusion.  even
> > >if it's redundant, i'd prefer to see all source files explicitly
> > >include all of the system header files they would normally need.  if
> > >you don't, you're just begging to have stuff break in surprising ways
> > >down the road.
> >
> > 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...

Rob

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

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.

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

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

> Maybe you think this is bad/stupid

Yes.

> (I might agree),

Then why bring it up?  How does putting forth what you acknowledge is a bad 
example support your position?

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

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

> Rich

Rob
-- 
Never bet against the cheap plastic solution.