Re: CVS commit: src/sys/sys

[Dave Sainty <dave%dtsp.co.nz@localhost>]

"Steven J. Dovich" writes:

> Dave Sainty wrote:
> > "Steven J. Dovich" writes:
> > > And that coddles the lazy at the expense of compile time. Consider
> > > the lexing costs for all the redundant including of required headers
> > > which have already been included. That can amount to a measurable
> > > difference in compile time, particularly when extended across the
> > > entire NetBSD source tree.
> > 
> > From the GNU cpp(1) info node:  "Once-Only Include Files"
> > -----------------------
> > 
> >    The GNU C preprocessor is programmed to notice when a header file
> > uses this particular construct and handle it efficiently.  If a header
> > file is contained entirely in a `#ifndef' conditional, then it records
> > that fact.  If a subsequent `#include' specifies the same file, and the
> > macro in the `#ifndef' is already defined, then the file is entirely
> > skipped, without even reading it.
> 
> I guess I knew that. But it isn't exactly portable behavior, now
> is it?

Well it is portable, it's just a question of performance.

> The fact that GCC tries to detect a sub-optimal coding
> practice does not make it suddenly palatable.  Is it better
> engineering to use portable constructs and behavior, or to further
> extend ones dependence on a particular implementation of otherwise
> standard technology, ie. should we add a few more pounds to the 5
> pound sack of GNUisms we are already carrying.

Well, the given change was apparently for an application program.  For
user-land programs I think it's hard enough to achieve compatibility
between systems as it is, without imposing OUR particular header
dependencies on the world and expecting application programmers to get
them right.

Other systems would have their own, possibly Quite Different header
ordering requirements.  Expecting the applications programmer to get
them right for every target system is a hard ask.

My opinion is that a header should expose an interface, and it should
deal with the system-specific quirks required to do that.

If that means that non-native toolchains take a little bit longer to
compile I can live with that.  I don't see that making us dependent on
a GNUism - obviously different toolchains will have their own
performance parameters.

Cheers,

Dave