Re: C++, extern "C" and () (was Re: [C patch] void_type_node)

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:

    >> That's an approach to the code-generation issues.  It doesn't
    >> solve the type-confusion that arises in C++-land.

    Jason> True.  Though in practice, people tend only to call C
    Jason> functions from C++, not pass around pointers to them.

I don't know.  In some code we've written, we've been stung by this
many more times than once.  And, independently, we've had customers
complain to us about this.  So, some subset of people do pass pointers
around a lot, or do other things that require type conversion.

    Jason> Sorry, I meant they usually aren't the only headers.  I
    Jason> believe we do work around all the problems.

Oh, OK.

    Jason> OK.  I suspect that they are not as interested in
    Jason> supporting obsolete systems as we have been; witness the
    Jason> people still playing with 4.3BSD.  It may be reasonable to
    Jason> just say we don't care about them for C++, but I'm
    Jason> reluctant.

I'm not so reluctant, I guess.  I'm all for 4.3BSD, but there are
freely available C++ compilers for those systems: old versions of
GCC.  If the consequence of using new versions of G++ is that they
don't play too nice with 4.3BSD, or that we have to do some extra
work to fix up their headers, I think that's OK.

    >> Good.  I'll try to put together the fixinclude magic, if we can
    >> agree on the right thing to do.  How about this, as an initial
    >> candidate:

    >> - If, in an X header we see an uprototyped function `f', we
    >> replace it with `f(...)'.  That's essentially what we're doing
    >> anyhow, right?

    >> Does this problem arise with non-X headers as well, on systems
    >> where if only for this being fixed, C++ would work nicely with
    >> the headers?

    Jason> I believe so, yes.  So you end up having to fix all the C
    Jason> headers, which was the reason for the implicit extern "C"
    Jason> stuff in the first place.

Hmm.

All right, here's another straw man.  For those headers that are
subject to IMPLICIT_EXTERN_C (so only on those targets where that
macro is defined *and* for only the system headers that the macro is
supposed to cover), we magically treat `f' in some weird way in the
compiler.  Maybe we give it `int f(...)' type; maybe we give it weird
unprototyped type.  Which one's right?

This appraoch would take this extension out of the way for all the
modern targets, and out of the province of otherwise conforming
programs on the antique targets.  How about that?

    Jason> The cruft really isn't that large now, is it?

:-)  No -- but it seems to come up a lot.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com