(j3.2006) binding labels and global identifiers

[Van Snyder]

On Wed, 2011-06-22 at 11:30 -0700, Bill Long wrote:
> I think that special-casing the words for the Unix f77 convention is not 
> the right way to fix this in the standard. It just invites future 
> problems when some other convention is encountered. The goal is to make 
> sure that a single linker symbol is not used as an identifier for two 
> different objects.  That goal is what the wording in the standard needs 
> to accomplish.  The current text in the standard for this is:
> 
> "The global identifier of an entity shall not be the same as the global 
> identifier of any other entity."
> 
> 
> This needs to be munged into something like
> 
> "A global identifier that identifies an entity shall not be the same as 
> a global identifier that identifies any other entity."
> 
> Data subgroup can probably do a better job of wordsmithing this, but I 
> think this is the general direction for a solution.

This isn't enough.  Clause 16 specifies what the global identifier of a
global entity is.  If a global entity is to have additional global
identifiers, other than its Fortran identifier and its binding label,
the standard needs to say so.

Then it should continue "There is no way, be examining the standard, to
determine all the global identifiers of a global entity."

Then stuff in Annex A specifying that the relationship of the global
identifiers of a global entity to the Fortran identifier of the entity
is processor dependent.

Then a recommendation that easily-found documentation accompanying
processors explains their name mangling schemes.

Thereby, all one needs do in order to write a portable program is to get
documentation from all known processor vendors and find their scheme for
name mangling.  Simple, right?

Otherwise, for the average processor, the standard provides no
interpretation of a program consisting of components in several
languages, and the program cannot, a fortiori, be standard conforming.

The standard ought to specify the global identifiers of entities that
have BIND(C).  One possibility is that there is no global identifier
other than the binding label of a global entity that has a binding
label.  Since BIND(C) requires explicit interface, the processor would
know this, and programmers can't care that there is no other global
identifier.

Processors can do what they want to do with global identifiers of global
entities that don't have BIND(C), leaving the same problem programmers
have always had with multi-language programs.  If we truly want to bless
this abomination, it ought to be mentioned in Annex A.  Personally, I
prefer what the standard says the binding label is if BIND(C) appears
without the name= clause.  That is, the Fortran identifier in lower
case.

> Cheers,
> Bill
> 
> 
> On 6/22/11 12:19 PM, mickistjames at gmail.com wrote:
> > If the Unix implementations don't mind a very small bit of backwards
> > incompatibility that affects only backwards compatibility of
> > certain codes that don't predate Fortran 2003 (and therefore are not
> > entrenched in the ecosystem), I think there's an easy fix to the
> > standard.
> >
> > Simply visit 3.1.1 which says
> >
> >  >A lower-case letter is equivalent to the corresponding upper-case
> > letter in
> > program units except in a character context (3.3).
> >
> > and append the text
> >
> >  >A final underscore is equivalent to a blank in a binding label context.
> >
> > With a stroke this would eliminate the user's ability to distinguish
> > between C functions "subr" and "subr_". The user hardly ever wants
> > this privilege and often gets it wrong anyway. It is now user's
> > responsibility
> > to avoid binding label "subr_" if user already has a global identifier with
> > name subr.
> >
> > Is it extra work at linking? Just barely. Say FORTRAN wants to interoperate
> > with a global procedure with binding label "subr_". If the final underscore
> > is equivalent to a blank, that creates an ambiguity--do you want to link
> > with subr or with subr_ ? Companion processor will have supplied only
> > one of these if user is playing fair. Implementation must figure out
> > which is
> > available in a pre-link step, and patch the name. C++ compilers have used
> > pre-link steps for years so technology may even already be in place.
> >
> > Micki
>