(j3.2006) binding labels and global identifiers
Wed Jun 22 14:30:13 EDT 2011
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.
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
> 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
> 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.
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
More information about the J3