correct "C" headers, higher priority
Benjamin Kosnik
bkoz@redhat.com
Fri Jun 1 11:25:00 GMT 2001
> > [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
More information about the Libstdc++
mailing list