Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bbn!apple!sun-barr!texsun!pitstop!sun!aeras!elxsi!beatnix!corbett
From: corbett@beatnix.UUCP (Bob Corbett)
Newsgroups: comp.lang.fortran
Subject: Re: Calling FORTRAN from C (messing with the namespace)
Message-ID: <2639@elxsi.UUCP>
Date: 6 May 89 18:19:08 GMT
References: <2846@tank.uchicago.edu> <5785@cbnews.ATT.COM> <10087@smoke.BRL.MIL> <11569@cgl.ucsf.EDU> <32033@sgi.SGI.COM>
Sender: news@elxsi.UUCP
Reply-To: uunet!elxsi!corbett (Bob Corbett)
Organization: ELXSI
Lines: 39

In article <32033@sgi.SGI.COM> bron@bronze.SGI.COM (Bron Campbell Nelson)
explains the reason UNIX f77 appends an underscore to each external name:

>There is a simple reason why this is done that I haven't seen posted
>yet (I may have missed it).  And that is precisely to *preserve* existing
>names and make it *possible* to use common library routines in both
>Fortran and C.
>
>It seems to me to be a reasonable solution to an ugly problem.  Is their
>a better one that someone knows about?
>
>--
>Bron Campbell Nelson
>bron@sgi.com  or possibly  ..!ames!sgi!bron
>These statements are my own, not those of Silicon Graphics.

The explanation Mr. Nelson gives is the one Stuart Feldman gave back in
1981.  Appending the underscore is probably the best solution given the
limitations of the UNIX linkage editor.

I think a better solution to the problem would be to allow a compiler to
specify the library from which a given routine is to be loaded in a load
module.  Name clashes between libraries and between libraries and user
code would be impossible.  There would need to be some way of overriding
the library specification, if only for debugging purposes.

The UNIX linkage editor causes some of UNIX f77's other problems as well.
It is why COMMON blocks cannot be initialized in separate load modules.
I know that multiple initializations of COMMON blocks are not allowed in
standard Fortran, but many other Fortran systems permit it.

I had hopes that the new linkage editor for System V, release 4 would solve
these and other problems.  From what I have read about the new loader format
ELF, it does not seem that they will be.  I am now designing my own loader
format, which will address these problems.  I would appreciate suggestions
regarding what a new loader format should contain.

					     Yours very truly,
					     Robert Paul Corbett