J3/02-188 To: J3 From: John Reid Subject: Interoperability edits Date: 7 May 2002 I would like to express my thanks to Richard Maine and Bill Long (specially Richard) for help with this paper. This is a follow-up to the papers on interoperability (02-136, 02-137) that I sent to the last meeting. I am, of course, delighted that so many of my suggestions were accepted. I have re-read this part of the standard and would like now to suggest the following. 28:2+. Add 'END ENUM' to the list. 43:20-21. Change 'a C struct type with which an entity of the derived type is interoperable (15.2.3)' to 'the C struct type with which the derived type is interoperable (15.2.3)'. [Section 4 is about types and 15.2.3 is about interoperability of types.] 64:23. Set 'enumerator' in italics. 64:29-65:1. Change 'an entity of type integer with that kind is interoperable (15.2) with an entity of the corresponding C enumeration type' to 'a type integer with that kind is interoperable (15.2.1) with the corresponding C enumeration type'. 71:32. Change 'subprogram or interface body' to 'procedure'. [We need to allow for ENTRY. There is no need to mention 'interface body' explicitly. This is simply one mechanism for giving the attribute to a procedure. For example, 12.4.1 makes no mention of interface blocks, but a procedure written in another language may use keyword arguments as long as it has an interface block. ] 77:10-11. Change to The BIND attribute for a variable or common block specifies that it is interoperable, that is, it may interoperate with a C variable with external linkage (15.3). [The present wording suggests to me that there has to be such a C variable.] 87:6. Add to the end of C558 'and the entity shall be an interoperable variable (15.2.4, 15.2.5)'. [As it stands, any entity may be given the bind attribute. I assume that the BIND statement is not intended to be applicable to a derived type or procedure. If it is, then more work is needed on the constraints here.] 87:10. Change '15.2' to '15.2.4, 15.2.5'. 87:11. Change 'entities' to 'variables and common blocks'. [Remind the reader that the BIND statement is not available for procedures or types.] 277:15. Change 'whose interface' to 'that'. [The BIND attribute is a characteristic of a procedure, see 12.2. It may, of course, be specified by an interface block.] 282:22-23. Change to The BIND attribute for a procedure specifies that it is interoperable, that is, it may interoperate with a C function with external linkage. [The present wording suggests to me that there has to be such a C function.] 381:14-15. Change ', C_NULL_CHAR ... C_VERTICAL_TAB,' to 'and the first column of Table 15.2'. 381:15. Change 'C_LOC, C_ASSOCIATED' to 'the procedures specified in 15.1.2'. [Need to include C_F_POINTER.] 383:1. Change 'target' to 'TARGET'. 383:2. Change 'has' to 'is of'. 383:8. Change 'object' to 'entity'. 384:7-9. Delete the J3 internal note and replace lines 7-9 by The following subclauses define the conditions under which a Fortran entity is interoperable. If a Fortran entity is interoperable, an equivalent entity may be defined by means of C and the Fortran entity is said to be interoperable with the C entity. There does not have to be such an interoperating C entity. 384:20+. Add paragraph: An intrinsic type and type parameters is <> if it is interoperable with a C type. 386:4. Change to 15.2.3 Interoperability of derived types and C struct types A Fortran derived type is <> if it has the BIND attribute. and move lines 11-17 to follow this. After these, add NOTE 15.10a The syntax rules and their constraints require that a derived type that is interoperable has components that are all data objects that are interoperable. No component is permitted to be a procedure or allocatable, but a component of type C_PTR may hold the C address of such an entity. 387:1-4. Change to 15.2.4 Interoperability of scalar variables A scalar Fortran variable is <> if its types and type parameters are interoperable, it is not polymorphic, and it has neither the pointer nor the allocatable attribute. An interoperable scalar Fortran variable is interoperable with a scalar C entity if their types and type parameters are interoperable. 387:5. Change to 15.2.5 Interoperability of array variables An array Fortran variable is <> if its types and type parameters are interoperable, it is not polymorphic, and it is of explicit shape or assumed size. 388:1. Change to 15.2.6 Interoperability of procedures and procedure interfaces A Fortran procedure is <> if it has the BIND attribute, that is, if it is specified with a . C1506 (R1225) A shall not be specified for a procedure with a dummy argument that is an assumed-shape array, polymorphic, optional, a procedure, of type and type parameters that are not interoperable (15.2), or an asterisk. NOTE 15.17a The rules and their constraints also require that a procedure that is interoperable has dummy arguments that are all data objects that are interoperable. No dummy argument is permitted to be a procedure or allocatable, but a dummy argument of type C_PTR may hold the C address of such an entity. The function C_LOC may be used to find the C address of a procedure or allocatable object and the subroutine C_F_POINTER may be used to establish a Fortran pointer whose target has a given C address. [Interoperability' of a procedure should be determined by the Fortran syntax independently of whether there is any corresponding C procedure.] 388:2-3. Change line 2 to The interface of an interoperable Fortran procedure is interoperable with a C function prototype if and delete line 3 (item (1) of the list). 388:5. Change 'interface describes' to 'procedure is'. 388:7. Change 'interface describes' to 'procedure is'. 388:7. Change 'interface' to 'procedure'. 388:10-11 and J3 internal note. Delete. [See my edit for 388:1. NOTE 15.10 makes it clear that C_LOC must be employed to pass procedures.] 389:8. Delete 'procedure'. 389:9+. In NOTE 15.20, add INTERFACE END INTERFACE around the Fortran code. 390:0. Interchange the two USE statements in NOTE 15.21. 390:7. Delete. [More general text now in 15.2.] 391:13-392:1. Change to An interoperable procedure may be defined either by means other than Fortran or by means of a Fortran subprogram, but not both. and do not start a new paragraph after this. 391:16-17. Delete 'that ... ' and make this an ordinary sentence instead of a list. [The deleted text is wrong for a procedure defined by an entry statement.] 392:0. Delete J3 note. I cannot see that there is much scope for debate here. There are words at the bottom of 281 explaining that RECURSIVE, PURE, and ELEMENTAL are not used in ENTRY statements. The fact that we have no such text for BIND and that is part of the syntax of the ENTRY statement says that this attribute may vary between entries to a subprogram. I claim that my edits for pages 71 and 391 fix this. 392:23+, NOTE 15.23. After the SUBROUTINE statement, add .. and after the present USE statement, add .. [The dots indicate that these procedures do something.] 395:18. After 'external procedures,' add 'procedure binding labels,'. 412:46-49. Change to (16) When execution of a RETURN or END statement causes a variable to become undefined, any variable of type C_PTR becomes undefined if its value was obtained by a call of C_LOC for the variable that becomes undefined or any variable that was then associated with the variable that becomes undefined. (17) When a variable with the TARGET attribute is deallocated, any variable of type C_PTR becomes undefined if its value was obtained by a call of C_LOC for the variable that is deallocated or any variable that was then associated with the variable that is deallocated. [We do not want to introduce a new form of association.] 421:7+. Add <> (15.2). The property of a Fortran entity that ensures that an equivalent entity may be defined by means of C.