This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: #include_next and removing of duplicate include dirs


On Sun, Sep 30, 2001 at 11:40:18AM -0400, Phil Edwards wrote:
> > | Wouldn't it be simpler and easier in the long run to cooperate
> > | with the C library?
> > 
> > Yes, that was mentionned sometime ago (probably just before we
> > released gcc-3.0) but there is no concretization yet -- at least
> > if memory serves me well.
>
> I think you're correct (again, if my own memory serves me well).
> For glibc, we just need to convince the glibc maintainers to allow
> C++ constructs in their headers, and (again, IIRC) they historically
> have been unwilling to do anything but C.  But given that they are
> chock full of GNU extensions, adding "#ifdef __cplusplus" shouldn't
> hurt.  I don't the conversation ever went any further.

They do already have extern "C" markers.  I have no idea how much more
complex it would be to do what the C++ standard wants, however, it
seems like a lot of it would fall into the category of _not_ doing
things that I personally think glibc shouldn't do in the first place.
Such as the "optimized" string macros.

> For Solaris and similar systems, I don't remember what the most
> recent problem was when their C++-aware headers get activated by our
> compatability attempts.  Multiple definitions of size_t and other
> stddef types, I think.

At least in theory, this is just a matter of figuring out how their
headers work and interfacing to them properly, yes?  I would volunteer
to help out if I still had a Solaris box to play with, but I don't.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]