🚀 go-pugleaf

In article <MATT.95Aug1101128@godzilla.EECS.Berkeley.EDU>  
matt@physics.berkeley.edu writes:
> In article <3vlhsd$s3i@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve  
Clamage) writes:
> 
> > >I can't understand why the committee is having such a hard time over  
this  
> > >issue. Why not just require a C++ implementation to specify with  
which C  
> > >compiler(s) (and versions) it is compatible on a given platform?
> > 
> > Let's suppose the committee makes exactly that requirement. Your C++
> > compiler manual says "This C++ compiler is compatible with the XYZ C
> > compiler, version 2.0.2," thus complying with the requirement. Are you  
now
> > better off than you were before?
> 
> To expand on Steve's points: what happens if XYZ corporation stops
> selling version 2.0.2 of its compiler?  Does that mean that your C++
> compiler is no longer standard-conforming?  Or what happens if you
> want to write a C++ compiler for a platform for which there isn't any
> C compiler?  (That's not as artificial a what-if as you might think:
> don't forget embedded systems.)
> 
> C and C++ are different languages.  I just don't see that cross-language
> compatibility are within the scope of the C++ standard.

I'm still puzzled. Obviously, extern "C" (or, for that matter, extern  
"SomeObscureLanguage") is in C++ right now and users depend on it, so it  
is here to stay. This implies that the standard will have to phrase *some*  
set of requirements about what it does. The question thus becomes what the  
standard should require. Here's an informal attempt:

- The standard should require the compiler vendor to specify what forms of  
external linkage are supported. At the very least, extern "C" and extern  
"C++" must be supported.

- For each of these forms of external linkage, the standard should require  
the compiler vendor to specify which name encoding scheme and calling  
conventions are used. As Steve Clamage pointed out, such a requirement  
could be satisfied by to referring to some well-defined ABI. For extern  
"C", 'same as C compiler XYZ version 2.0.2' would be good enough, as long  
as that compiler defines its name encoding scheme and calling conventions.

- For extern "C", the standard could say that the calling conventions must  
the same as for extern "C++", which was my original point. The benefit of  
this would be that pointers to extern "C" and extern "C++" functions are  
assignment compatible.

- For other linkages forms, the standard could require the use of a  
typedef to declare pointers to such functions, and specify that such  
pointers are not assignment compatible accross different linkages:

typedef extern "XXX" void (*PXXXF)();
extern "YYY" void f();
PXXXF p = f;		// error: incompatible linkage

- Wil