Re: Status of the PPH implementation

[Lawrence Crowl <crowl at google dot com>]

On 5/25/12, Diego Novillo <dnovillo@google.com> wrote:
> On 12-05-25 14:54 , Joseph S. Myers wrote:
> > On Fri, 25 May 2012, Diego Novillo wrote:
> > > On 12-05-25 12:25 , Jason Merrill wrote:
> > > > On 05/25/2012 11:37 AM, Joseph S. Myers wrote:
> > > > > and it should be possible to eliminate the __need_*
> > > > > special cases for some system headers by having more,
> > > > > smaller headers set up to define individual types.
> > > >
> > > > I was thinking the same thing.
> > >
> > > Yes.  Increased modularity in system headers is a must.
> > > That is likely going to be one of the hard things to fix.
> > > I'd rather have that discussion in the standards forums,
> > > as I suspect some of the same will be discussed for the
> > > module proposal.
> >
> > If feature test macros (or, similarly, assert.h depending on
> > NDEBUG) are the problem then that would need to be addressed
> > for standards - but if it's __need_* conditionals then those
> > are an implementation detail for GCC and glibc and any changes
> > would need sorting out in the communities for those toolchain
> > components.  (I don't know how good the libstdc++ headers are
> > at modularity, so I'm thinking about C headers, both those
> > provided by GCC and those provided by glibc.)  Or is the issue
> > with system headers something else entirely?
>
> There were several problems:
>
> - Lack of double inclusion guards.
>
> - Lack of modularity. For instance, accepting parameters to change
> the meaning of the file, stddef.h is the canonical example.
>
> - Mutually recursive inclusion.  Some files seem to work in tandem,
> they include each other conditionally just in case the other has
> not been included yet.
>
> - Some files refuse to be compiled in isolation because they are
> always included by a wrapper file (e.g. the bits/* files).
>
> - Files that use #include_next (they cannot be compiled in
> isolation).
>
> - Some files give syntax errors when compiled in isolation
> because they are missing symbols. for example, ext/algorithm
> needs __gnu_cxx::is_sorted.
>
> Those are the ones I could gather on a quick grep through my
> build logs.  Lawrence may remember more.

Not off the top of my head.  While some of the problem is artifacts
of implementation, those artifacts are often driven by conflicting
standards requirements.  The C standard says x.h only exports symbols
a, b, and c.  The Posix standard says x.h exports d.  From there
you descend into what the OS folks fondly call "header hell".  :-)
The root problem is in the standards, and given the legacy code
base, it's going to be really hard to fix.  I suspect that with
convincing we could get alternate headers (or modules) defined with
better behavior.  I doubt we could change the existing headers.

-- 
Lawrence Crowl