Re: need finer-grained "C" header scheme information

[jtc at acorntoolworks dot com (J.T. Conklin)]

Benjamin Kosnik <bkoz@fillmore.constant.com> writes:
> Kay. So, the "C" compatibility headers are working with my hacked
> newlib.  Basically, I've used the --enable-cheaders=c configuration,
> plus an additional layer of includes.
> 
> This new layer of "C" includes is include/c_compatibility. It just
> injects std names into the global namespace, and is intended for the
> C++ compiler only. 
> 
> The only issue remaining is represented by the following:
> 
> 1) QNX
> --enable-cheaders=c
> (no need for c_compatibility headers as "C" headers already inject)
> 
> 2) current newlib config
> --enable-cheaders=c
> need c_compatibility headers 

This isn't entirely sufficent for QNX.  

While using --enable-cheaders=c avoids the conflicts caused by both
the system headers and the c_std headers trying to inject std names
into the global namespace, the result is that the names will always be
injected regardless of whether <cfoo> or <foo.h> is #included because
the "magic" to disable <foo.h> from injecting symbols is not present 
in <cfoo>.

So it seems that the cheaders=c will need some mechanism for disabling
the "C" headers from injecting.  QNX injects if _STD_USING is defined.
I'm not sure whether there are any other systems that ship with ISO
C++ conforming "C" headers, and if so what mechanism(s) are used to
cause/suppress names being injected.  If there aren't now, I wouldn't
be surprised to see them in the near future.  

If C++ conforming C headers become the norm, I think it's a safe bet
we'll see an equal number of mechanisms for causing/suppressing names
to be injected.  If so, I forsee that libstdc++'s "c" headers become
twisty nests of conditionals similar to those in gcc's own stddef.h,
etc.  Perhaps this can be mitigated somewhat by using whatever
influence we can muster to convince the maintainers of the most
important "free" C libraries (newlib, glibc, *BSD, etc.) into using
the same mechanism.

Perhaps I'm being terribly naive.  But if this can be pulled off,
supporting libstdc++ on the most common targets becomes trivial and
special cased headers will only be needed for legacy/proprietary
systems.

        --jtc

-- 
J.T. Conklin