🚀 go-pugleaf

In article <DCyD2M.46H@tigadmin.ml.com>,
Julian Pardoe LADS LDN X1428 <pardoej@lonnds.ml.com> wrote:

>However, pragmatically there *is* an ``obvious'' meaning for ``extern "C"''
>in many cases (e.g. as defined by that same vendors C compiler) so it's
>probably worth keeping it, even if it's not well-defined.  I just
>don't envy the Standard Committee's job trying to find the wording to
>express what ``extern "C"'' means.

I think it can be done easily:

Linkage is part of the type of a function (and therefore a function
pointer type includes this information).  A "C" function can be called
just like a C++ function except for overloading and possibly default
arguments.

A function type defined within the scope of an extern "C" declaration
is a "C" function.

Everything else comes out of existing rules:

If the "C" function is not defined in a C++ source file the behavior is
implicitly undefined (it's not a C++ function so the standard can't say
what happens).

A "C" function obeys C++ syntax rules, not C.

If a "C" function is called by a pointer to C++ function, the behavior
is explicitly undefined (this is calling through a pointer to a different
type of function, just like calling a function returning double using a
pointer to function returning int).  If a "C++" function is called using
a pointer to "C" function, the behavior is likewise undefined.

Note that I said nothing about the C language.  Quality of implementation
will encourage compilers to make "C" functions use a calling convention
compatible with C compilers; the standard can not force them to do so except
by requiring all C++ compilers to have a C mode and incorporating the C
standard into the C++ standard.

The restriction that a compiler know the type of a function at the point
of the call should be sufficient for it to generate code with the correct
calling sequence.  It may be desirable to modify the argument checking
rules.  The C++ rules can work for C, but not for other languages in general.


-- 
    John Carr (jfc@mit.edu)