cik@l.cc.purdue.edu (Herman Rubin) (07/24/87)
Many of us know the problems of linking programs produced by different compilers, and of using external arrays or common blocks in such programs. I propose that every language have a means of declaring a name used in such a way as exact, that is the introduction of underlines is not done in forming the object file. This would enable the user who, for some reason, wishes to combine programs from different compilers not to have to worry about what mangling of names is done by this compiler on this system. In fact, some of the systems at Purdue have their FORTRAN compilers pass the names unchanged, and some use the (ugh!) prepending and postpending of underlines. This means that one cannot use the same combination of FARTRAN and C source codes on the two machines. The C programs are for a library which is to be FORTRAN, as well as C, callable, and which cannot be written in FORTRAN. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu or pur-ee!stat-l!cik or hrubin@purccvm.bitnet
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/25/87)
In article <557@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >This would enable the user who, for some reason, >wishes to combine programs from different compilers not to have to worry >about what mangling of names is done by this compiler on this system. There is a lot more to worry about than simply matching of external names by the linker. Inter-language linkage can be quite tricky, although some vendors have made a stab at supporting it (notably DEC's VMS). The problem is basically that different languages can pass objects between procedures that other languages cannot handle. The external name space available to the programmer is already quite badly hampered by having to avoid conflicts with system library names. It would be much worse if one had to worry about conflicts with all possible languages on the computer! I for one am much happier with Fortran names not colliding by accident with C names; for one thing, it makes it possible for a Fortran support library to be written in C, as many are.
daniels@cae780.TEK.COM (Scott Daniels) (07/27/87)
In article <6173@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <557@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >>This would enable the user who, for some reason, >>wishes to combine programs from different compilers not to have to worry >>about what mangling of names is done by this compiler on this system. > >There is a lot more to worry about than simply matching of external >names by the linker. Inter-language linkage can be quite tricky,... Perhaps what we need is something more of the following form: #pragma interface_name c_name = external_name Which would maker all uses of "c_name" in the C source show as "external_name" in the linker. This allows you to avoid the nasty assembly language step if all you want is to avoid name convention problems (ie if a C call can be made "close enough", or a C procedure can cope with the others call format.) This certainly fits smoothly in the language, since there is no need to use this feature within a full C-world, and the "wart" stands out in a single place. FROM: Scott Daniels, Tektronix CAE 5302 Betsy Ross Drive, Santa Clara, CA 95054 UUCP: tektronix!teklds!cae780!daniels {ihnp4, decvax!decwrl}!amdcad!cae780!daniels {nsc, hplabs, resonex, qubix, leadsv}!cae780!daniels
jagardner@orchid.UUCP (07/30/87)
In article <4314@cae780.TEK.COM> daniels@cae780.UUCP (Scott Daniels) writes: >Perhaps what we need is something more of the following form: > #pragma interface_name c_name = external_name >Which would maker all uses of "c_name" in the C source show as "external_name" >in the linker. This allows you to avoid the nasty assembly language step if >all you want is to avoid name convention problems (ie if a C call can be made >"close enough", or a C procedure can cope with the others call format.) > Our compiler uses two pragmas: #pragma equate c_name external_name tells the compiler to map all occurances of "c_name" to "external_name", sort of a #define for the linker; #pragma alias c_name external_name ... tells the linker to give the "c_name" object the following alternate names. David Tanguay
ron@topaz.rutgers.edu (Ron Natalie) (08/04/87)
The main reason that people use underline prepending in compilers is
that the compilers output to assembler as an intermediate and they
did not want to check (or wished to always be consistant) for ambiguities
of the following nature:
int R6;
R6 = 3;
Yields in PDP-11 assembler...
mov #3, R6
which without underscore prepending means move 3 to the stack pointer
which is not what the C code implies. The ORACLE IBM 370 C compiler
among its multitude of other bugs had this problem.
SUGGESTION:
What you really want to be able to do is to tag certain C symbols with
other names when they get assembled or linked. This allows you to use
C to reference symbols whose names are not legal C identifiers (like
they have funny symbols in them like $ or %). Since doing this is
going to be implementation specific to begin with, you can have a
feature in C (perhaps associated with the ANSI pragma construct) that
binds a C name to an external name in the source code,
#pragma bind sys_zark "sys$ZARK"
Of course, it probably can also be done in existing compilers by some
post processing on the output of the compiler to change the symbol names.
-Ron