Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mimsy!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.misc,comp.lang.c,comp.lang.fortran,comp.lang.pascal Subject: Re: Names of non-local objects Message-ID: <6173@brl-smoke.ARPA> Date: Sat, 25-Jul-87 05:16:37 EDT Article-I.D.: brl-smok.6173 Posted: Sat Jul 25 05:16:37 1987 Date-Received: Sat, 25-Jul-87 22:04:49 EDT References: <557@l.cc.purdue.edu> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Distribution: world Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 18 Xref: mnetor comp.lang.misc:581 comp.lang.c:3278 comp.lang.fortran:173 comp.lang.pascal:211 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.