Re: correct "C" headers, higher priority

[Benjamin Kosnik <bkoz at redhat dot com>]

> That would be the right thing to do for Linux and other glibc-based
> installations (when you can, do the right things).  It won't work for
> everyone.

Yeah but it'll put a conformant solution in place, for people who are 
willing to do the extra work (on linux, maybe BSD, solaris 8). For non-free, 
non-open OS's, we'll have to punt to c_std for the time being.

> > There are now a series of bugs in GNATS about strchr, strcpy, etc all 
> > being ambiguously declared, or not declared, etc. It's something that 
> > everybody is going to run into and yes, it can be worked around but it's 
> > kind of lame to have everything else working pretty well and have 
> > something so basic tripping people up.
> 
> Yeah.  Didn't c_std used to work, event if it was no where near compliant?

...before madness with the undef's struck...

What do you think of Scott's idea with making a string.h?

> I've been making slow progress on my c_legacy headers idea.  It seems there
> are some places in the code that depend on the c_std headers not being
> compliant (that is, they introduce names in the global namespace), and as soon
> as one is fixed, another pops up.  

Yeah. You might as well send patches for this in as you find them.

> I feel better when I check other implemetations of the C++ standard library.
> With a few notable proprietary exceptions (eg. Solaris 8), nobody else has
> bothered making their <c...> headers compliant.  Perhaps it's just too hard?

Dinkumware uses the approach of putting everything in the .h into std if 
__cplusplus is true. I'm thinking that might be less of a hack than what 
is done now. 

Although, this does seem to be a real problem.

-benjamin