🚀 go-pugleaf

In article hmu@sunsystem5.informatik.tu-muenchen.de, schuenem@informatik.tu-muenchen.de (Ulf Schuenemann) writes:
>
>IMHO the standard should say something like:
>1. 'extern "XXX"' linkage _allows_ the compiler to use create code differently
>   to 'extern "YYY"' linkage.
>2. For names with external linkage that is not 'extern "C++"' there _may_ be
>   restrictions compared to 'extern "C++"'.
>3. Any C++ compiler shall support at least 'extern "C++"' and 'extern "C"'.
>4. If not noted otherwise this standard describes only the behavior of
>   'extern "C++"' linkage.

I believe the above points are already covered by the standard.

>5. If a name from the Standard C Library is not 'extern 'C++"' then it
>   _shall_ be 'extern "C++"' (see 17.3.2.2,2). 'extern "C"' linkage _should_
>   allow _further_ compatibility to C implementations.

I wonder if you have a typo in the first sentence of #5; I don't understand it.
The second sentence is not appropriate in a normative part of the standard,
since it doesn't make a requirement that can be verified.

>
>IMO this gives us what we want and what we can get:
>ad 1. A compiler which allows 'extern "Fortran"' is still a legal C++ compiler.

That is already the case.

>ad 2. It is _legal_ (but not necessary and not in the scope of the standard)
>      to have a restriction like
>      - functions with extern "C" linkage can not be overloaded
>      - functiontypes with extern "Pascal" linkage are not compatible to
>        functiontypes with extern "C" or "C++" linkage.

That is already the case.

>ad 5. As we've seen in the discussion before, it is not sensible to require
>      compatibility to a specific C implementation. It not even makes sense
>      to make it implementation defined to which it is compatible, as there
>      might be no C implemenation at all or it could just name C implementations
>      that are not available (yet / any more).

Agreed, and that is why the standard says so little about 'extern "C"':
there isn't much that can be said.

---
Steve Clamage, stephen.clamage@eng.sun.com