Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.c++ Subject: Re: Linkage & a question on name mangling Message-ID: Date: 25 Dec 89 21:15:48 GMT References: <1545@aber-cs.UUCP> <259312BD.11972@paris.ics.uci.edu> Sender: pcg@aber-cs.UUCP Distribution: gnu Organization: Coleg Prifysgol Cymru Lines: 97 In-reply-to: rfg@ics.uci.edu's message of 23 Dec 89 05:53:00 GMT In article <259312BD.11972@paris.ics.uci.edu> rfg@ics.uci.edu (Ron Guilmette) writes: >and that 'extern "C"' does *not* imply >the "extern" storage class, because it is not a storage class? But it *does* (at least partially). In 7.4: "Otherwise, a function declared in a linkage specification behaves as if it was explicitly declared `extern'". Let me pick this nit: extern "C" per se does not; what happens is that in C (and C++) function declarations have by default storage class extern. >Notice that since mangling does not apply to variable names yet... Yes. Can somebody please tell me why that is the case? It seems to me that all of the "type checking" effects that are squeezed out of the linker via name mangling function names would be equally applicable to the problem of assuring that the types of variables and (extern) const's were consistant across object files. What's the story? More or less like the problem with incorporating in a mangled procedure name the return type: that duplicate declarations with different types result in no error. Examples: extern int square(float); extern unsigned count = 0; /* in file a.C */ extern float square(float); extern long signed count = 1L<<24; /* in file b.C */ If the "return type" is mangled in the name, the clash is not detected. For variables this is especially poignant because C++ 2.0 forbids more than one definition, even if they are uninitialized. On the other hand, as I had indicated, with templates you actually may *want* this to happen, because you can instantiate procedures and classes over more than a type. Well, I have not thought out the gory details, but I guess that some mangling will have to happen. Given that we are into language lawyering :-> , here are some more unsual, but well known ("admittedly the ice is thin here" K&R) insecurities of C and C++ declarations: typedef signed; /* 1 No name for this type. */ typedef unsigned weight; /* 2 See later */ extern struct fcb; /* 3 fcb is just a struct */ static; /* 4 Unnamed int, local linkage */ auto struct point {int x,y;}; /* 5 Struct declaration */ register enum let {a,b,c}; /* 6 Enum declaration */ register enum pound {one}; /* 7 Enum declaration */ typedef point &pointref; /* 8 A simple typedef */ extern double let(let); /* 9 What's this? */ extern z(auto char) /* 10 New in C++: unnamed argument */ { weight; /* 11 Unnamed variable, type weight */ weight pound; /* 12 Variable pound, type weight */ auto; /* 13 For good measure... */ weight weight; /* 14 Variable weight, type weight */ point point; /* 15 Legal in C++. Ugh! */ register float; /* 16 Unnamed variable */ static fcb *fcb; /* 17 What's this? */ static pointref; /* 18 But next is illegal */ static point [1]; /* 19 Type is array of points */ auto char (*)(); /* 20 Unnamed ptr to procedure */ extern char (*)(); /* 21 Unnamed ptr to procedure */ } If you have slightly morbid tastes, try these with your friendly C++ compiler (or, with some changes, a C compiler). GNU C++ 1.35 behaves quite well; it does warn about empty declarations, but there are some problems, at least for syntax. I have not tried to assemble the resulting compiler output, but likely there are problems there as well. So, BUG REPORT for GNU C++: #21 breaks the compiler; #5, #6 and #7 have a funny storage class, and I *think* that it is illegal, even if ineffective. #9 gets a warning, but should probably be an error. #19 is faulted, but might be instead legal. As usual, I wonder what would happen with cfront. As usual, I think that typedef and enum don't mesh well with the rest of C and C++, and that the ice has become too thin in too many places. Well, an italian way of saying is "L'hai voluta la bicicletta? Adesso PEDALA!" (Didn't you ask for a bicycle? Now WORK IT!) -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk