Re: () in C++ (was Re: [PATCH] C and C++ ICEs)

[Mark Mitchell <mark at codesourcery dot com>]

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

    >> So, Jason, what is your opinion about always treating extern
    >> "C" void foo (); extern "C" void (*ptr) (); as extern "C" void
    >> foo (void); extern "C" void (*ptr) (void); ?

    Jason> I'm opposed to it.  That feature is there to deal with C

I thought you would be. :-)

    Jason> library headers that have not been updated to include
    Jason> proper prototypes, such as the X library headers on some
    Jason> systems.

As far as I can tell, EDG's compilers do not do this, so that suggests
that IRIX and Compaq's OS are already OK with respect to this issue.

As Nathan pointed out, rewriting these as `(...)' doesn't work on
targets where varargs and unprototyped functions are treated
differently, anyhow.  So, at present we've got a non-conforming,
tricky to maintain, somewhat incorrect extension. :-( 

It's also not the stated purpose of -fpermissive to provide changes to
the semantics of the language; instead, it's too avoid errors on
things like calling an undeclared function, or implicit int, i.e.,
things that have no defined meaning within the language.  It would be
nice if it were an invariant that code that compiled without
-fpermissive also compiled with -fpermissive, and did not change its
meaning.  Otherwise, if I ship you my library, and you choose to
compile its headers with -fpermissive, because you are using X on some
weird system, you may find that my library does something different
than you wish it would.  (For example, that overloading works
incorrectly, or that the calling convention used to call my functions
is wrong.)

(An alternate strategy would be to simply *ignore* such declarations
in the scope of an extern "C" under the influence of some weird flag.
Then, fall back on -fpermissive's ability to handle undeclared
functions.  Yes, that would break taking the address of such a
function, unless we did some very odd bit where the declarations were
visible only when addressed.  OK, that's sounding ridiculously ugly.)

Why not have fixincludes fix them?  If we really want `()' to be the
same as `(...)' in an extern "C" header, and we think that's really a
problem with system headers, then, at least abstractly, fixincludes is
the right tool for the job.

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