J3/99-262

Date:    1999/11/30
To:      J3
From:    /interop
Subject: Issues 86 and 203 (constraints on BIND(C))


Edits and references refer to J3/99-007R2

1. Issue 86

Issue 86 on page 42 in section 4.5.1 asks why the combination of
SEQUENCE and BIND(C) in the definition of a derived type is
prohibited. The reason is that the goal of adding the BIND(C)
attribute in the definition of a derived type is to let the Fortran
processor know that the corresponding derived types could be read in
by a C processor. Thus the Fortran processor has to store the derived
types in such a way that the goal of passing the derived type to C is
attained. If we would allow the user to add a SEQUENCE statement in
the data-component-part of the derived type definition, then a
conflict with respect to the storage of the data could occur. In order
to avoid this potential conflict, the combination of SEQUENCE and
BIND(C) in the definition of a derived type is prohibited. See also
note 4.39 on page 54.

Edit:

[42:1-10] Delete J3 note

[42:10+] Add note:

If BIND(C) is present, SEQUENCE is prohibited, because otherwise the
requirements of BIND(C) could be in conflict with the requirements of
SEQUENCE.

2. Issue 203

Issue 203 on page 42 in section 4.5.1 asks why procedure pointers are
prohibited from having the BIND(C) attribute. The reason that the
design of C-Fortran interoperability does not allow the interoperation
of Fortran and C pointers. Note that the passing of a C-pointer to a
procedure from Fortran to C is possible through the use of the C_LOC
intrinsic function, with as argument a procedure with a BIND(C)
attribute. This note is added as edit to the section on procedure
pointers (12.3.2.3).

Edits:

[42:17-21] Delete J3 note

[272:17+] Add note:

A procedure pointer can not interoperate with a C pointer. However, it
is possible to pass a C pointer to a procedure from Fortran to C
through the use of the C_LOC intrinsic function. The argument of the
C_LOC intrinsic function is then a procedure with a BIND(C)
attribute.