(j3.2006) binding labels and global identifiers

Malcolm Cohen malcolm
Wed Jun 22 20:30:59 EDT 2011

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.

The trivial mapping is nonetheless a mapping.  MANY Fortran-linker name mappings 
in the 60s/70s were not in fact the completely trivial mapping.  Some were ... 
less impressive than others (the one where the linker only had a 5-character 
limit and when converting it dropped IIRC the 2nd one of the Fortran name, was 
deeply unimpressive!).  But usually this was invisible UNLESS you were doing 
mixed-language programming (cue the reason for the underscore in the first 

>If the processor in addition invents "subr_" or "_subr_" or "subr__" or
>"_subr__" because the procedure name is "subr" and makes that a global
>identifier, that appears to me not to be standard conforming.

Global identifiers are not linker names.  Linker naming conventions are entirely 
outwith the scope of the standard.

At the time when we were adding C interoperability, people thought (and even 
claimed!) that we were not trying to standardise linker naming conventions.  We 
thought we put enough weasel words in to cover the usual cases.  Well, obviously 
not enough to satisfy some people.

I note you've entirely ignored my point about the validity of the name.

By using BIND(C) you are entering a different world - as I showed in my example. 
Good luck trying to get *that* to work!

Like it or not when interoperating with another language there are namespace 
issues to deal with.  Many of these are legacy issues; 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 and for some strange reason even the C committee 
didn't decide to cut off the legacy nose to spite the modern face.

Fortran should certainly not be going there.

................................Malcolm Cohen, Nihon NAG, Tokyo. 

More information about the J3 mailing list