This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++, extern "C" and () (was Re: [C patch] void_type_node)
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: C++, extern "C" and () (was Re: [C patch] void_type_node)
- From: Jason Merrill <jason at redhat dot com>
- Date: 11 Jul 2000 10:00:55 -0700
- Cc: nathan at codesourcery dot com, gcc-patches at gcc dot gnu dot org
- References: <u9k8gb88bz.fsf@decepticon.cygnus.com> <3934EC8F.4F3FFC44@codesourcery.com> <u9aefs1w4e.fsf_-_@casey.soma.redhat.com> <20000710005150D.mitchell@codesourcery.com>
>>>>> Mark Mitchell <mark@codesourcery.com> writes:
> I still am not convinced by the "old C headers require this" argument,
> which is the root cause of this debate. In other words, I'm still not
> at all convinced we can't just define the problem out of existence by
> removing this extension.
I don't like that idea (surprise, surprise).
> - There are semantic issues raised on the lists here that suggest
> that there is no easy way to know what do with `extern "C" void
> f()'; that can mean lots of things, and it's hard to
> simultaneously conform to the standard and be generous.
There is an easy way. Treat it like C: a parameter list of NULL_TREE. The
middle-end knows what to do with that for C, so it can do the same thing
for C++.
> - There are lots of problems with C headers in C++; this is only one of
> them.
Yes, and we make an effort to work around all of them.
> - The major relevant example here is the X headers -- but on systems
> that old are they really the only headers that have these
> problems? Or other problems that prevent compilation with G++?
No, they usually aren't the only ones. That doesn't seem like an argument
against the extension.
> - EDG does not support this usage, suggesting that many tools
> vendors don't find support for this extension necessary.
EDG does not market to end-users; many tools vendors have control of their
own headers.
> - There are other means for dealing with this issue, including
> upgrading the X headers, or fixincludes, or ...
Upgrading the headers is not a real option.
This sort of thing is easier to deal with in the compiler, which has more
semantic information, but I would be open (if skeptical) of a fixincludes
solution.
> I believe that this extension might have been appropriate in the past,
> and even that there are people who still make use of it. But they're
> almost certainly on antiquated non-GNU systems.
How about just disabling it on NO_IMPLICIT_EXTERN_C targets?
Jason