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

[Benjamin Kosnik <bkoz at redhat dot com>]

> This isn't entirely sufficent for QNX.  

Right.

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

I'm hoping free systems use c_compatibility headers. That's my
suggestion for both newlib, glibc, and BSD libc. I've tried to do this
in the past with glibc, but the nesting and additional complexity proved
too difficult for me at the time. At this point, newlib is a
proof-of-concept implementation and the modified newlib headers are at
testsuite parity with current c_std headers or better. (Obviously, the
testsuite changes that are in this patch were found because of the c
model's stricter behavior. That's where the 'or better' part comes
in...)

For QNX, using c_compatibility headers is possible, but not advised,
since the underlying "C" headers already have chosen to inject. Why do
this work again?

For the QNX (and others, say solaris)  case, I suggest you invent a way
to do this. My suggestion is to use os/qnx/*/bits/os_defines.h to match
the underlying "C" library injection macro (in your case _STD_USING) to
a general libstdc++-v3 injection macro (say, _GLIBCPP_INJECT_FROM_STD or
whatever).

Then you'd need to mark up the include/c/ headers with the general
libstdc++-v3 macro to deal with this. I'm open to this kind of patch, or
possible other approaches.

I leave this bit to you. I think I've a solution in place for
non-proprietary systems that works pretty well. 

Also, I think the configuration stuff is now flexible enough to handle
most of the "C" header schemes I know about. It wasn't really, before
this week (although most bits where there.)

Thoughts? I realize there's been substantial movement on this code this
week, and will give you some time to digest the changes.

 -benjamin