(j3.2006) binding labels and global identifiers

[Jim Xia]

j3-bounces at j3-fortran.org wrote on 06/14/2011 06:28:09 AM:

> Please respond to robert.corbett, fortran standards email list for J3
> 
> One of Oracle's other engineers working on Fortran raised
> a question regarding conflicting binding labels and global
> identifiers (see Clause 16.2 of 10-007r1).  He pointed out
> that many Fortran implementations, including Oracle's,
> construct the linker name for an external procedure or
> common block by adding a low line to the end of the global
> name of the procedure or common block.  Consider the
> following program:
> 
>       MODULE variables
>         USE ISO_C_BINDING
>         PRIVATE
>         PUBLIC x
>         REAL, BIND(C, NAME="subr_") :: x = 0.1
>       END
> 
>       SUBROUTINE subr
>         USE variables
>         PRINT *, x
>       END
> 
>       PROGRAM main
>         CALL subr
>       END
> 
> This program caused a problem for every implementation I
> tried.  I was amused that it failed in a different way for
> each implementation.  Nonetheless, the program does not
> appear to violate the requirements set out in Clause 16.2.
> The global identifier "subr" and the binding label "subr_"
> are different according to the language of Clause 16.2.


XLF, by default, doesn't suffer from this problem as it doesn't append 
underscores to the external procedure names.  However, it does have an 
option to turn on the underscores, which will upset the linker for this 
example.


> 
> Is the program presented above intended to be standard-
> conforming?  Implementations could easily be made to handle
> the program by using a different mapping of global names to
> linker names.  Making such a change might break backward
> compatibility.


Naming schemes (or name mangling) fall out of the scope of the standard as 
I see it.  It is the programmers' responsibility to avoid duplicate global 
names.  On a similar note, I've seen large scale applications fail to 
build because of duplicate symbols at link time.  This is a fairly common 
problem.


Cheers,

Jim Xia

Compiler Testing, X10 & XLF
IBM Toronto Lab at 8200 Warden Ave,
Markham, On, L6G 1C7
905-413-3444
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20110614/13ff9631/attachment.html>