Re: correct "C" headers, higher priority

[Benjamin Kosnik <bkoz at redhat dot com>]

> > [biting my tongue still]

> Of course the problem is that *some* names found in the underlying
> C headers have to be hidden because C++ supplies something different.

I'm of the mind to provide a set of patches to allow the dinkumware 
approach for the include/bits/c headers. The downside is that the changed 
signatures (strchr, et al) won't be implemented (Or at least I can't figure out a way to do it 
correctly.)

I'm also tempted to remove the 

#define strchr __glibcpp_strchr

bits in the c_std headers, along with the changed signatures. 

I don't know which is worse: having the changed signatures and then being 
unable to use the "C" .h headers, or being able to use both the cFOO.h 
and FOO.h headers and not  get the correct signatures.

I'm thinking the first (what is done now) is worse.


After seeing somebody else confirm my experiences with the shadow 
headers, I think a whole new way of dealing with this is justified. 

from Scott:
I was at one point trying to use the c_shadow implementation.  But it
was uphill going --- mainly because whenever you tried to use a header
or identifier not in the C++ standard, things didn't work.  So i spent
a while writing additional c_shadow wrappers for all the other,
non-C++ headers our code was using (think things like sys/sem.h,
arpa/inet.h, dirent.h, ucontext.h ...) plus adding a whole bunch of
additional identifiers to the existing headers (drand48, mkstemp,
pthread_join, sigprocmask, setsid, ...).  The result was pretty messy,
and not particularly portable.


-benjamin