(j3.2006) binding labels and global identifiers

Malcolm Cohen malcolm
Wed Jun 22 04:44:11 EDT 2011

The standard is not quite as unopen to interpretation as some commentors are 

> So if the processor mangles an identifier that the standard says is a
> global identifier, and manages to create one that's the same as a
> different global identifier specified in your program, I'd be inclined
> to say the processor, not the program or the standard, is the culprit.

It certainly can be argued that the program is at fault, because it violates the 
"acceptable to the companion processor" rule.

Specifying a bind-name that is the same as part of the Fortran runtime or indeed 
C runtime is obviously not going to be acceptable.  I can certainly argue 
further that bind-names that match the "linker name" generated for a non-BIND(C) 
part of the program is likewise not acceptable.

>> underscore to the end of a procedure name.  The irony is that the
>> convention of adding an underscore was designed to prevent (accidental)
>> interoperability.
> This was a bad idea from the outset.  It's a shame it got perpetuated.

That's your opinion.  I disagree; while not the name mangling scheme I would 
have designed if starting from scratch, it is a reasonable one.

>In this case, there seem to be a couple of resolution paths:
>1) Say it really is the rule

Doesn't work.  Whatever stupid wording you come up with to try to sledgehammer 
these vendors to make their next release incompatible with all their previous 
releases, I guarantee you I can find a loophole.

In extremis there is always the loophole of declaring that that C compiler is 
not the companion processor for the purposes of standard conformance.  That we 
interoperate with that C compiler in all the normal situations when the user is 
not actively trying to break things is just an extension.

In any case, making a bunch of vendors produce incompatible releases is not 
promoting portability, quite the reverse.

>2) Figure out some way to say "don't do that" to programmers without looking 
>too arbitrary.

Name mangling and the available names for the companion processor are simply 

Users who are trying to break things should just stop.

This is not limited to things like "subr_"... if a Fortran library internally 
has the private module procedure
   REAL FUNCTION pi() BIND(C,NAME="malloc")
     pi = 3.14
it can be quite entertaining to watch someone try to use that library from their 
C program.

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

More information about the J3 mailing list