Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!janus.Berkeley.EDU!jbuck From: jbuck@janus.Berkeley.EDU (Joe Buck) Newsgroups: comp.lang.c++ Subject: Re: c++ name mangler sought Message-ID: <41560@ucbvax.BERKELEY.EDU> Date: 3 Apr 91 00:52:09 GMT References: <5165@atexnet.UUCP> <71574@microsoft.UUCP> Sender: nobody@ucbvax.BERKELEY.EDU Distribution: usa Organization: U.C. Berkeley Lines: 29 In article robertk@lotatg.lotus.com (Robert Krajewski) writes: >Actually, at least one of the C++ books lays out the cfront name >mangling scheme, and says it should be followed by other >implementations so that C++ tool writers won't have so much >(arbitrary) work to do. Such a book is merely being short-sighted, since name mangling is not required. Consider a linker that can take arbitrarily long global symbol names (many systems have these already). No problem, right? Now, eliminate any restriction on what characters may appear in the global symbol name (other than, say, a 0 byte to terminate it). Now, suppose you have a prototype for a function int AClass::func(int,const char*,BClass&) const; What symbol should be searched for by the linker? Well, how about "AClass::func(int,const char*,BClass&) const"? Who says you need to mangle at all? What we do now reminds me of the kludgery the Eunice (Unix on top of VMS) system goes through to represent arbitrary Unix filenames on top of a filesystem with more restricted filenames: right, it does name mangling. cfront needs to do name mangling because it produces C. But true C++ compilers don't need to do name mangling at all; they only need a minor modification to the linker. Someone else suggested this earlier; it's not original with me. -- Joe Buck jbuck@janus.berkeley.edu {uunet,ucbvax}!janus.berkeley.edu!jbuck