[J3] Is BIND (C [ , NAME = scalar-default-char-constant-expr ]) where scalar-default-char-constant-expr has zero length legal?

John Reid John.Reid at stfc.ac.uk
Fri Jan 11 11:23:29 EST 2019



Daniel C Chen via J3 wrote:
> For "1. subroutine 'foo' has the BIND attribute, but no binding label. 
> So 'foo' can be called within Fortran, but 'foo' must not be referenced 
> in C due to lack of a binding label. ", is based on the following 
> wording in the standard:
> 
>     18.10.1 p4:
>     A reference in C to a procedure that has the BIND attribute, has the
>     same binding label, and is defined by means
>     of Fortran, causes the Fortran procedure to be invoked.

This does not say anything about the case of a procedure without a 
binding label. This is what we say in Modern Fortran Explained p. 376:

"If the character expression has zero length or is all blanks, there is 
no binding label. The procedure may still be invoked from C through a 
procedure pointer and, if this is the only way it will be invoked, it is 
not appropriate to give it a binding label. In particular, a {private} 
module procedure must not have a binding label."

I hope and believe that this is correct.

Best wishes,

John.





> It seems it requires the Fortran procedure to have a binding label. In 
> the case the binding label is absent (NAME=''), such a Fortran procedure 
> seems cannot be referenced from C.
> 
> For 2 "If "subroutine foo() bind(c, name='')" is in an interface, 
> Fortran cannot call a C routine named 'foo' as well. .." is based on the 
> following wording in the standard:
> 
>     18.10.1 p2:
>     If the procedure is defined by means other than Fortran,
>     • it shall be describable by a C prototype that is interoperable
>     with the interface, and
>     • if it is accessed using its binding label, it shall
>     *– *have a name that has external linkage as defined by 6.2.2 of
>     ISO/IEC 9899:2011, and
>     *– *have the same binding label as the interface.
> 
> It seems referencing such a procedure requires a binding lable. In the 
> case the binding label is absent (NAME=''), the procedure can probably 
> passed as an argument but not directly referenced.
> For instance, the following code seems not to be standard conforming 
> based on the above wording?
> 
> INTERFACE
> SUBROUTINE FOO() BIND(C, NAME='')
> END SUBROUTINE
> END INTERFACE
> CALL FOO()
> END
> 
> VOID FOO() {
> ...
> }
> 
> All of the above seems imply that NAME='' should be treated as if NAME= 
> is not specified but it still have a binding label that is same as the 
> Fortran name.
> 
> 
> XL Fortran Development, Fortran Standard Representative
> IBM Toronto Software Lab
> Phone: 905-413-3056
> Tie: 969-3056
> Email: cdchen at ca.ibm.com
> http://www.ibm.com/software/awdtools/fortran/xlfortran
> 
> Inactive hide details for Vipul Parekh via J3 ---01/09/2019 04:02:57 
> PM---On Wed, Jan 9, 2019 at 11:27 AM Daniel C Chen via J3 Vipul Parekh 
> via J3 ---01/09/2019 04:02:57 PM---On Wed, Jan 9, 2019 at 11:27 AM 
> Daniel C Chen via J3 < j3 at mailman.j3-fortran.org> wrote:
> 
> From: Vipul Parekh via J3 <j3 at mailman.j3-fortran.org>
> To: General J3 interest list <j3 at mailman.j3-fortran.org>
> Cc: Vipul Parekh <parekhvs at gmail.com>
> Date: 01/09/2019 04:02 PM
> Subject: Re: [J3] Is BIND (C [ , NAME = 
> scalar-default-char-constant-expr ]) where 
> scalar-default-char-constant-expr has zero length legal?
> Sent by: "J3" <j3-bounces at mailman.j3-fortran.org>
> ------------------------------------------------------------------------
> 
> 
> 
> 
> On Wed, Jan 9, 2019 at 11:27 AM Daniel C Chen via J3 
> <_j3 at mailman.j3-fortran.org_ <mailto:j3 at mailman.j3-fortran.org>> wrote:
> 
>     ..
>     Based on the wording in the standard that Bill pointed out,
>     ..
>     2. If "subroutine foo() bind(c, name='')" is in an interface,
>     Fortran cannot call a C routine named 'foo' as well. ..
> 
> 
> 
> Re: 'If "subroutine foo() bind(c, name='')" is in an interface, Fortran 
> cannot call a C routine named 'foo' as well.', is it not 
> processor-dependent again whether Fortran can call a C routine named 'foo'.
> 
> Please see the following where on Windows x64 platform, one processor 
> seems to apply a Fortran procedure label which is "the same as the name 
> of the procedure using lower case letters" when NAME is specified with 
> zero length in a BIND statement.  And because that labels happens to be 
> the same as what the companion processor does for a C function, a coder 
> can manage to call a C routine from Fortran,  I believe this is not 
> portable.  But I don't think the Fortran standard disallows it either.
> 
> Given this code in C:
> 
> #include <stdio.h>
> void foo() {
>      printf("foo says Hello!\n");
> }
> 
> and the Fortran code as:
> 
> module a
>     interface
>        subroutine foo() bind(C, name="")
>        end subroutine
>     end interface
> end module
> 
> module b
> contains
>     function foo() result(r)
>        integer :: r
>        r = 42
>     end function
> end module
> 
> program p
>     use a
>     use b, bar => foo
>     call foo()
>     print *, "bar returns ", bar()
> end program p
> 
> This processor allows linking a program to provide the output:
> foo says Hello!
>   bar returns  42
> 
> My thinking is the above is conforming i.e., a module procedure by 
> itself is not a global identifier (if I get section 19.2 in 18-007r1 
> right) unlike a module name itself.  So module b above should be able to 
> CONTAIN a procedure named 'foo' regardless of anything in other 
> modules.  Now when USEd in a scope such as program p with the renaming 
> option, the global identifiers in that scope are the interface toward 
> subroutine foo() with proc-lang-binding-spec but no binding label and 
> 'bar'.  The resultant code on that platform allows invocation of C 
> function via that processor's convention for the Fortran procedure label 
> and the Fortran function via the 'bar' label.  Does anyone think this is 
> incorrect?
> 
> Thanks,
> Vipul[attachment "graycol.gif" deleted by Daniel C Chen/Toronto/IBM]
> 
> 


More information about the J3 mailing list