(j3.2006) Interesting F2003-ism
Van Snyder
van.snyder
Thu Feb 22 14:22:57 EST 2007
On Thu, 2007-02-22 at 12:53 -0600, Bill Long wrote:
>
>
> Aleksandar Donev wrote:
> > Andy Vaught wrote:
> >
> >
> > > I will start the process by not
> > > implementing the restriction on binding-labels in g95...
> > >
> > Good, since that restriction makes perfectly sensible programs illegal
> > too, most notably my favorite example:
> >
> > module A
> > interface
> > subroutine p_A(f, a) bind(c, name='p')
> > type(c_ptr) :: f
> > integer, value :: a
> > end subroutine p1
> > end module
> >
> > module B
> > interface
> > subroutine p_B(f, a) bind(c, name='p')
> > type(c_ptr) :: f
> > integer, value :: a
> > end subroutine p1
> > end module
> >
> > Note that here one is merely giving two different Fortran names in two
> > *distinct* modules to the same interface and same C procedure.
> >
>
> Bind(c) does not in any way imply that the procedure is written in C.
> Indeed, in a large class of cases, the routine is written in Fortran.
>
> Suppose, for the example above, the user writes (in Fortran)
> subroutines p_A and p_B, and writes another subprogram that uses both
> modules and then calls P. What routine gets called? How does the
> proposed "extension" in g95 propose to deal with this? Just rely on
> the loader to produce a duplicate symbol error? The rules in 16 are,
> in part, designed to avoid loader errors.
Aleks's example would not cause a duplicate symbol error. Fortran
refrences to either p_A or p_B would be transformed to linker references
to p, not definitions of p. Bill's example would cause duplicate symbol
errors. One needs to keep in mind while pondering this problem that
interface bodies are not the same thing as subroutine definitions. They
are (in this case) subroutine declarations.
--
Van Snyder | What fraction of Americans believe
Van.Snyder at jpl.nasa.gov | Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.
More information about the J3
mailing list