J3/99-270r1 Date: 1999/12/02 To: J3 From: /interop Subject: Edits for issues 165, 166, 167, 97, 163, 170, and 101 (Interop.) References: 99-007r2, 99-205r2, 99-011r2 Issue 97 - [404:1-22] Issue 101 - [409:1-5] Issue 163 - [361:21-32] Issue 165 - [405:1-33] Issue 166 - [405:43-49] Issue 167 - [407:13-22] Issue 170 - [408:8-12] [[Editor, please note that some of the changes applied by 99-205r2 are modified by this paper.]] 1) Unresolved issue 165 asked for a more meaningful definition of interoperate. It also points out that the text talks about data objects and procedures interoperating in some places, and in others it speaks of types interoperating. We've attempted to clear that up under item 2) below. Finally, the issue points out that some places seem to draw a distinction between things that can interoperate and things that do interoperate. Initially that distinction was intentional, but we've since introduced the concept of "linking" to handle the distinction, so the terminology "can interoperate" will revert to "does interoperate". [284:26] Change "cannot" to "does not" [284:30-31] Change "is of a type that cannot interoperate with some C type, then the procedure cannot interoperate with any C function." to "does not interoperate with any C entity, then the procedure does not interoperate with any C function." [404:25-30] Replace with: "If a variable, structure component, subprogram or procedure is declared in a way that allows an equivalent declaration of an entity in a C program, the entity in the Fortran program is said to <> with such a C entity. The following sections the conditions under which a Fortran entity interoperates with a C entity. [[Note 16.x]] A Fortran entity can interoperate with more than one C entity. [[End Note]]" [405:1-33] Delete J3 issue 165. [406:3-5] Change "A C string can interoperate. . . C_CHAR." to "A Fortran array of type character with a kind type parameter equal to C_CHAR interoperates with a C string." After applying the edits of 99-205r2: (i) In the edit for [84:33+] Change "cannot interoperate" to "does not interoperate" (ii) In the edit for [411:35+] 2) Unresolved issues 166 & 167 take issue with the fact that section 16.2 says that things interoperate in certain situations, unless explicitly or expressly prohibited. The only explicit prohibition appears in [404:27-28], and will be repeated in the places identified instead. The edit for issue 165, above, removes the prohibition on POINTER and ALLOCATABLE that appeared in 16.2, and the following edits insert the prohibition into the subsections of 16.2. Issue 167 also takes issue with the fact that at times the text describes types as interoperating, and at other times it describes entities of those types as interoperating. The latter was intended. Finally, the term "interoperable" is used in several places, when only the term "interoperate" is defined (this wasn't identified by any issue). The latter will be used consistently. [41:16-17] Change "to interoperate with the corresponding C struct as defined in 16.2.4." to "for an entity of a C struct type with which an entity of the derived type interoperates (16.2.4)." [64:15] Change "Enumerations and enumerators" to "Entities of an enumeration type" [64:16] Change "enumeration types and enumerators" to "entities of the enumeration type" [405:37-38] Change "of the indicated type and kind type parameter, that is not expressly prohibited from interoperating with any C entity, is interoperable" to "that has neither the POINTER nor the ALLLOCATABLE attribute, and that is of the indicated type and kind type parameter, interoperates" [405:40-41] Change "then there is no Fortran type and type parameter that is interoperable with the C types" to "there is no Fortran entity that interoperates with a C entity of the C types" [405:43-49] Delete J3 note 166. [407:11-12] Change "that is not expressly prohibited from interoperating with any C entity (16.2) is interoperable" to ", that has neither the POINTER nor the ALLOCATABLE attribute, interoperates" [407:13-22] Delete J3 note 167. [408:14-15] Change "that is not expressly prohibited from interoperating with any C entity is interoperable" to ", that has neither the POINTER nor the ALLOCATABLE attribute, interoperates" [408:24] Change "is interoperable" to "interoperates" [408:25] Change "is interoperable" to "interoperates" [408:26-27] Delete "There is no C entity. . . parameterized derived type." The preceding is already implied by 4.5.1 [41:41-42]. [408:44] Change "the types are interoperable" to "entities of a derived type interoperate with entities of a C struct type" 3) Unresolved issue 97 - part 1 This issue has to do with whether the C_PTR type should be required to be a type with private components. Our concern here was that an implementation might, for some reason, find it inconvenient to implement a C_PTR as a derived type. For example, if the companion processor always passes structs by reference (creating a copy in the called routine), but has no trouble passing pointers by value, the Fortran processor might find it easier to make the pointer a type alias for some kind of integer. We wanted to avoid placing an undue burden on the processor. A quick survey of implementors indicated that, if the standard permits the C_PTR type to be a type alias, most would make it a type alias for an integer - both for ease of implementation, and to allow users who want to to do non-portable things with entities of type C_PTR. Unresolved issue 97 - part 2 The second part points out that the section on type aliases describes them as hiding the underlying implementation, but that isn't true. We agree. A disciplined user can use a type alias to effectively hide the underlying implementation type, but the feature doesn't prevent undisciplined use. [63:32] Delete ", while hiding which type that is" [404:1-22] Delete J3 issue 97. 4) Unresolved issue 163 Binding labels are currently described as global entities of a program. Instead, a binding label should be described as something that identifies a global entity, in much the same way that a name can identify a global entity, but the name itself is not the global entity. [361:18-20] Replace with "Program units, common blocks, external procedures, and variables that have the BIND attribute are global entities of a program. A name that identifies a program unit, common block, or external procedure shall not be used to identify any other such global entity. A binding label that identifies a global entity of the program shall not be used to identify any other global entity of the program, nor shall it be the same as a name used to identify any other global entity of the program, ignoring differences in case. [[Add note]] The name of a global entity may be the same as a binding label that identifies the same global entity. [[End note]]" [361:21-32] Delete J3 note 163 After applying edits for 99-205r2, remove text added for [369:4+]. (Or just don't make the change from 99-205r2 to begin with.) 5) Unresolved issue 170 notes that C procedures need explicit interfaces. These edits update the example to provide such an interface. [408:3+] Add "INTERFACE BIND(C) SUBROUTINE FOO(C) USE ISO_C_BINDING TYPE(C_PTR), VALUE :: C END SUBROUTINE FOO END INTERFACE" [408:7] Delete "! FOO is a C routine" [408:8-12] Delete J3 note 170 6) Unresolved issue 101 points out that an example should use the ISO_C_BINDING module. There's also another error in the example. [408:38-39] Replace with "USE ISO_C_BINDING TYPE, BIND(C) :: MYFTYPE" [409:1-5] Delete unresolved issue 101.