(j3.2006) binding labels and global identifiers

Van Snyder Van.Snyder
Wed Jun 22 22:40:16 EDT 2011

On Wed, 2011-06-22 at 17:30 -0700, Malcolm Cohen wrote:
> Now then, "name mangling" is just a pejorative term for the mapping between the 
> language-level name and the linker name.
> >I can't imagine how I got along for a decade on the 7094, and two on the
> >1108, without any name mangling.
> I can't either, unless you were using an interpreter.

To avoid distorting the discussion with pointless arguments about
terminology, let me remark instead that on the IBM 7094 using the IBSYS
Fortran IV compiler, and on the Univac 1108 using Fortran V (both Univac
and Athena), and the Univac Fortran 77 compiler, the linker name was
exactly the same as the Fortran name.

This never caused problems.  In fact, it made it very easy to interface
Fortran + ASM.

I wrote many programs that consisted of Fortran + ASM, Fortran + COBOL
(yes COBOL) and Fortran + PL\1.

> one might ask why malloc 
> (and sin and cos and ...) are even in the user namespace at all, but they were 
> originally in that namespace

They weren't in the namespace of the Univac 1100 compilers (well, Univac
didn't have malloc).  SIN was something like NSIN$.  I don't remember
whether the compiler's runtime names were in the namespace on the 7094.

So "they were originally in the namespace" seems to be a feeble reason
for trying to cope with Stu's mistake.  They were "originally" in the
namespace of Stu's compiler, which was far from the first one.  Maybe
his claim to be the first -- and slowest -- Fortran 77 compiler was
accurate, but there was nothing about Fortran 77 that was sufficiently
different from Fortran 66 to require the linker name to be different
from the Fortran name.

> Like it or not when interoperating with another language there are namespace 
> issues to deal with.  ... for some strange reason even the C committee 
> didn't decide to cut off the legacy nose to spite the modern face.

If processors feel the need to produce a linker name that is different
from the Fortran name (in the no-BIND(C) case), they should use a name
that cannot be a valid C name, or a valid runtime library name.  I
remember that somebody put at-signs in their linker names.  Univac
solved the problem by making runtime linker names invalid Fortran names.

One might complain that some processors cause problems by using an
algorithm that generates linker names that are different from the
Fortran names of global entities, but are perfectly good C names.  I
don't see, however, why the standard has to bother with this mistake.

More information about the J3 mailing list