sidlo@skinner.epps.kodak.com (John Sidlo) (03/23/91)
Does anyone know where I can find a c++ name mangler? This program would take a string like "x::f(int)" and produce the corresponding typesafe version "f__1xFi", for example. (The ARM talks about this in sect 7.2.1c). We are working on calling c++ methods from Dec Scheme->C, which has a facility for defining references to standard c functions. I'll post a summary of responses. Thanks in advance.
jimad@microsoft.UUCP (Jim ADCOCK) (03/29/91)
In article <5165@atexnet.UUCP> sidlo@skinner.epps.kodak.com (John Sidlo) writes: |Does anyone know where I can find a c++ name mangler? This program would |take a string like "x::f(int)" and produce the corresponding typesafe |version "f__1xFi", for example. (The ARM talks about this in sect 7.2.1c). Name mangling is not "c++", but rather is implementation dependent. Which compiler do you want a name mangler for?
robertk@lotatg.lotus.com (Robert Krajewski) (04/03/91)
In article <71574@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: In article <5165@atexnet.UUCP> sidlo@skinner.epps.kodak.com (John Sidlo) writes: |Does anyone know where I can find a c++ name mangler? This program would |take a string like "x::f(int)" and produce the corresponding typesafe |version "f__1xFi", for example. (The ARM talks about this in sect 7.2.1c). Name mangling is not "c++", but rather is implementation dependent. Which compiler do you want a name mangler for? 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. Of course, some implementations must extend the mangling scheme because the environment demands it: for example, 16:16 (segmented) Intel architectures need the NEAR/FAR pointer distinction MPW provides a little library function for demangling char *'s. Other development environments ought to provide such a service, too. (Preferably with a standard name and interface.)
jbuck@janus.Berkeley.EDU (Joe Buck) (04/03/91)
In article <ROBERTK.91Apr2173901@lotatg.lotus.com> 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
aed@netcom.COM (Andrew Davidson) (04/04/91)
> >Article 10088 (9 more) in comp.lang.c++: >From: jbuck@janus.Berkeley.EDU (Joe Buck) >Subject: Re: c++ name mangler sought >Date: 3 Apr 91 00:52:09 GMT > 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. > I think in general most of use to not realy care if function names are mangled or not. we are just trying to get dyanmic linking and loading to work. In general we need some way to map the functions names we write in C++ or any other lang, with the correct symbol in the object file we are loading. Andy -- ----------------------------------------------------------------- "bede-bede-bede Thats all Folks" Porky Pig Andy Davidson Woodside CA. aed@netcom.COM -----------------------------------------------------------------
ned@pebbles.cad.mcc.com (Ned Nowotny) (04/04/91)
In article <1991Apr3.170401.4903@netcom.COM> aed@netcom.COM (Andrew Davidson) writes:
=>
=>>
=>>Article 10088 (9 more) in comp.lang.c++:
=>>From: jbuck@janus.Berkeley.EDU (Joe Buck)
=>>Subject: Re: c++ name mangler sought
=>>Date: 3 Apr 91 00:52:09 GMT
=>>
=>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.
=>>
=>
=>
=>I think in general most of use to not realy care if function names are
=>mangled or not. we are just trying to get dyanmic linking and loading
=>to work. In general we need some way to map the functions names we
=>write in C++ or any other lang, with the correct symbol in the object
=>file we are loading.
=>
Some of us would also like to link objects compiled by one C++ compiler with
objects compiled by another. Is the ANSI C++ committee looking into linking
and C++ object libraries? Or, does anyone care about libraries; modules as
opposed to classes; name space pollution; interoperability with compilers for
C, C++, Ada, etc. which may, by necessity, come from different vendors; and
so on?
(By the way, are there any reasons, other than political, that G++ does not
use the same name mangling scheme as the one documented in the ARM? Or has
that changed since G++ 1.37.1?)
Ned Nowotny, MCC CAD Program, Box 200195, Austin, TX 78720 Ph: (512) 338-3715
ARPA: ned@mcc.com UUCP: ...!cs.utexas.edu!milano!cadillac!ned
-------------------------------------------------------------------------------
"We have ways to make you scream." - Intel advertisement in the June 1989 DDJ.steve@taumet.com (Stephen Clamage) (04/04/91)
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. Apart from extensions which Robert mentions, some other changes may be needed. The cfront scheme assumes the linker distinguishes upper and lower case, which not all linkers do (notably VMS). Not all linkers support long names, and some mangled function names can become very long indeed. Sometimes the fully-mangled name must be hashed to a shorter version. The cfront scheme produces names which are legal C identifiers. Shorter mangled names can be produced if the linker allows characters in names which are not legal in C (or C++) identifiers. Finally, as has been pointed out elsewhere (by me, among others), name mangling is an implementation detail. If the linker can recognize type information passed by the compiler, name mangling might not be necessary at all. -- Steve Clamage, TauMetric Corp, steve@taumet.com
jbuck@janus.Berkeley.EDU (Joe Buck) (04/04/91)
In article <18279@cadillac.CAD.MCC.COM> ned%cad@MCC.COM (Ned Nowotny) writes: >Some of us would also like to link objects compiled by one C++ compiler with >objects compiled by another. Is the ANSI C++ committee looking into linking >and C++ object libraries? Or, does anyone care about libraries; modules as >opposed to classes; name space pollution; interoperability with compilers for >C, C++, Ada, etc. which may, by necessity, come from different vendors; and >so on? Yes, there certainly are good arguments for compatibility. >(By the way, are there any reasons, other than political, that G++ does not >use the same name mangling scheme as the one documented in the ARM? Or has >that changed since G++ 1.37.1?) You'd need to ask Mike Tiemann for the details. I do know this: FSF has always had a very strict policy against reading the code (e.g. Unix source code, cfront source code) that is being replaced by copylefted code, so they can avoid any accusation of theft of trade secrets, violation of copyright, etc. They also can't read any Bell Labs internal memos, etc, that document internals. When the first g++ came out, I doubt that the cfront mangling scheme was published anywhere in the open literature. How could he have found it out? From what I've seen, though, the cfront and g++ schemes are very similar. They could, perhaps, be made the same and maybe ANSI should look into this. This shouldn't be done by slavishly reverse engineering cfront; if the C++ community decides it needs to be done in a uniform way, the uniform way should be written up in a document and everyone should fix their compilers. Still, I think that in the long run name mangling should go away. For library compatibility, though, we need more than name mangling compatibility. We need to define the stream class (at least partially: vendors and libg++ could provide extra methods); we need to shoot those who want to name the base class of their library Object and therefore prevent anyone else from using it, etc. :-) -- Joe Buck jbuck@janus.berkeley.edu {uunet,ucbvax}!janus.berkeley.edu!jbuck
steve@taumet.com (Stephen Clamage) (04/05/91)
ned@pebbles.cad.mcc.com (Ned Nowotny) writes: >Some of us would also like to link objects compiled by one C++ compiler with >objects compiled by another. Is the ANSI C++ committee looking into linking >and C++ object libraries? Or, does anyone care about libraries; modules as >opposed to classes; name space pollution; interoperability with compilers for >C, C++, Ada, etc. which may, by necessity, come from different vendors; and >so on? The ANSI C++ committee is interested in these issues. Some of these cannot be addressed. For example, how can the C++ commitee specify what an Ada compiler must do? Is it right to *require* that a conforming C++ compiler be able to link to Ada programs? What if there is no Ada compiler for the intended host? What if one becomes available the day after the C++ compiler is released? What if there are two incompatible Ada compilers on the system -- is it enough to support just one of them? If the committee addresses object libraries, we must specify how it is to be done on all possible systems, an impossible job. Programmers usually think in terms of a compiler which works with text files to produce object files which are then linked into a self-contained executable file. NOT ONE OF THESE ELEMENTS IS NECESSARY -- text files, an identifiable compiler, identifiable object files, separate executable files. There are already other ways to make programs, and we do not want to prevent still better methods of making them from coming about. The name-space pollution problem is a thorny one. There have been some proposals, none of which was judged adequate. The issue always seems to hang up on the idea of a central clearing-house for names. How is this to be done, remembering that international cooperation is required? Real-world programmers are rightly concerned with getting their jobs done efficiently now. Standards committees have to keep such things in mind while looking toward the future. -- Steve Clamage, TauMetric Corp, steve@taumet.com
steve@taumet.com (Stephen Clamage) (04/05/91)
jbuck@janus.Berkeley.EDU (Joe Buck) writes: >We need to define the stream class (at least partially: >vendors and libg++ could provide extra methods); The ANSI C++ committee is working on a standard set of stream classes, similar to what is provided by AT&T. >we need to shoot those >who want to name the base class of their library Object and therefore >prevent anyone else from using it, etc. :-) Only shoot them? Joe is obviously more tender-hearted than I am. -- Steve Clamage, TauMetric Corp, steve@taumet.com
purtill@morley.rutgers.edu (Mark Purtill) (04/09/91)
steve@taumet.com (Stephen Clamage) writes: >The name-space pollution problem is a thorny one. There have been >some proposals, none of which was judged adequate. The issue always >seems to hang up on the idea of a central clearing-house for names. >How is this to be done, remembering that international cooperation >is required? A central clearing-house for names sounds like a dreadful idea to me. How are you going to force vendors to register their names? Answer: you can't. It seems to me that some sort of module structure would be a better idea. I'm sure this has been suggested -- why was it judged not adequate? ^.-.^ Mark Purtill purtill@dimacs.rutgers.edu (908)932-4580 (O) ((")) DIMACS, P.O. Box 1179, Rutgers U., Piscataway, NJ 08855 (908)220-6905 (H) ********** Note new area code! We are now (908) rather than (201)! **********
steve@taumet.com (Stephen Clamage) (04/09/91)
purtill@morley.rutgers.edu (Mark Purtill) writes: |steve@taumet.com (Stephen Clamage) writes: |>The name-space pollution problem is a thorny one. There have been |>some proposals, none of which was judged adequate. The issue always |>seems to hang up on the idea of a central clearing-house for names. |>How is this to be done, remembering that international cooperation |>is required? | A central clearing-house for names sounds like a dreadful idea |to me. Me, too, hence "inadequate". |It seems to me that some sort of module structure |would be a better idea. I'm sure this has been suggested -- why was |it judged not adequate? This doesn't sound familiar. What did you have in mind? -- Steve Clamage, TauMetric Corp, steve@taumet.com
rfg@NCD.COM (Ron Guilmette) (05/12/91)
In article <41560@ucbvax.BERKELEY.EDU> jbuck@janus.Berkeley.EDU (Joe Buck) writes: >... 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? Who indeed? >... 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. Not quite true. Many "true" C++ compilers may still produce assembly code and assemblers tend to have their own restrictive rules regarding what does and does not constitute a valid assembly-level identifier. If you had a scheme where you could sneak arbitrary strings past the assembler (as identifiers) and get the assembler to write those strings into the object file, I suspect that you would be home free. I suggested in the UI/PLSIG awhile back that assemblers ought to have a special pseudo-op especiall for this purpose so that C++ compilers could say (for example): .alias test__Fif,"test(int i, float f)" Someone suggested that this was not a sufficient solution. I don't recall having asked that peoson why it was not. Perhaps it isn't, but I think that having this kind of a `.alias' pseudo-op would be most helpful for C++ compilers. -- // Ron ("Loose Cannon") Guilmette // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // New motto: If it ain't broke, try using a bigger hammer.