J3/02-136R2 Date: 28 Feb 2002 To: J3 From: R. Maine Subject: Issues 341, 342, 345, and 346 INTRODUCTION This paper is in response to 02-136. Several things from 02-136 are incorporated; others are expanded on or done differently. Paper 02-136 addressed unresolved issues 341, 342, 345, 346, and 347, so this paper does also. The central thrust of this paper is to reorganize some material relating to interoperability, gathering most of it into clause 15, with references as needed elsewhere. Currently, the material is scattered into several places in the document, notably clauses 5 and 12. Paper 02-136 proposed some such gathering, but this paper takes it farther. Issues 341 and 342 are the central ones here, the others being somewhat peripheral to the reorganization. In one area, this paper makes the opposite suggestion from paper 02-136. Although there are arguments for both sides, this paper favors the term "BIND attribute" instead of "BIND(C) attribute". Either form has the potential for requiring changes if an additional language binding is introduced. Both forms appear in the existing text; the intention here is to change the "BIND(C)" forms where used in the context of the name of an attribute. The syntax still includes the "(C)". This is consistent with the intent expressed in recent J3 meetings. (The author of this paper actually prefers the global substitution of LANG instead of BIND, but leaves that as an independent question not addressed here.) EDITS In c04, Fix BIND(C) types. John's fix doesn't work because we aren't talking about data entities here - just type definitions. But we don't really need to say that anyway because procedure components are always pointers and so are already covered. We do need to rule out intrinsic types that aren't interoperable; the original words missed that. Also, refer to "BIND attribute" where we can. Finally, I suggest moving the requirements specific to the BIND attribute to c15, with a reference here. (An alternative minimal fix is easy if that move is rejected). [41:16] "definition of a derived type specifies BIND(C)" -> "derived type has the BIND attribute". [53:9-11] "BIND(C)" -> "BIND" twice. [42:7-12] Move these constraints to [376:1-] and reword as follows. "C15xx (R423) A derived type with the BIND attribute shall not be a sequence type. C15xx (R423) A derived type with the BIND attribute shall not have type parameters. C15xx (R423) A derived type with the BIND attribute shall not have the EXTENSIBLE or EXTENDS attribute. C15xx (R423) A with the BIND attribute shall not have a . C15xx (R423) Each component of a derived type with the BIND attribute shall be a nonpointer, nonallocatable data component with interoperable type and type parameters." [45:27+] Insert a new para before the note. "Derived types with the BIND attribute are subject to additional constraints as specified in 15.2.4." In c05 [67:30] "" -> "" per 02-136. Following 02-136, but using our improved definitions. [67:33-34] "a variable" -> "an interoperable variable (15.2)" [67:32-33] delete "POINTER... The". It is all covered by the preceding edit. [73:1-4] Replace heading and para with "5.1.2.4 BIND attribute for data entities" The BIND attribute for a variable or common block specifies that it is interoperable with a C variable with external linkage (15.2.7)." Delete issue 341 on pg 73. [see also edit for 270:6+] Note 5.10 - move note to [73:6+] after C547, which is basically what it refers to. [73:7-8] Delete sentence "The BIND...(15.2.7)". It is now covered (and better so) by constraints. Following John's lead, but using improved definitions, [83:3+] Add "C558a (R526) If a is a common block, each variable of the common block shall be interoperable (15.2)" In c12 Per John, 250:9,22,25,26. Change to . 250:24. Delete ', '. (typo) [264:19-24] Replace the two constraints and para with "C1238 (R1225) A shall not be specified for a procedure whose interface is not interoperable (15.2.6)." (Yes, that covers all that was here, plus the things that were omitted from here. Get it right in one place and then reference it instead of duplicating pieces of it incorrectly all over the place.) 264: Delete Note 12.38. This is a random incomplete repetition of the requirements. Better to look at the real ones in 15.2.6. [267:1-3] Delete C1249. The new C1238 covers this and much more. We don't need to incorrectly duplicate it here. The old versions both omitted different parts. [269:37-40] Delete the sentence beginning "If...letters". Per issue 345 and 02-136, most of this is not needed. I almost added a short para at [269:29+] to cover the material suggested by issue 345, but I realized that I'm not at all sure we really want that and if we did, we missed some cases. (Is there any reason to disallow mixture of BIND(C) and non-BIND(C) entries in the same subprogram? Seems to me it is a potentially useful thing...assuming, of course, that one considers ENTRY useful in the first place. If we were going to disallow it, we only did it in one direction, which seems odd. Lets just force the BIND(C) on an ENTRY to be explicitly specified if that's what you want; it doesn't seem like a big deal - the potential confusions from making it implicit seem bigger.) 270: Issue 345. Delete the issue. (I'm not yet sure I'm happy with the wording of the following edit, but it follows both existing wording and that of 02-136. Might fix this better later, but at least need something here to substitute for deleting words like this from 5.1.2.4 in the process of fixing issue 341). [270:6+] Add para "The BIND attribute for a procedure specifies that it is interoperable with a C function with external linkage." [270:7-280:11] Replace with "Interoperation with C functions is described in 15.4." (all this material is now in 15.4, with the wording changed, hopefully improved.) Subclause 15.2.3 has little relation to defining interoperability, which is the subject of 15.2. It belongs better in 15.1, as it describes procedures in the module. We'd like it to be a subclause under 15.1, so we move much of the existing 15.1 down a level (there shouldn't be a 15.1.1 without also having a 15.1.2). 371:19- Insert section heading "15.1.1 Named constants and derived types in the module". [372:23] "shall be..use" -> "is". Part of this was redundant and part was false (15.2.2 does not describe the use). 372:24 Delete line. [374:4-] Insert the following note at the end of 15.2.2. "The function C_LOC can be used to return an entity of type C_PTR with the C address of a procedure or allocated allocatable variable. The entity of type C_PTR is interoperable and thus may be used in contexts where the procedure or allocatable variable is not directly allowed. For example, it could be passed as an actual argument to a C function. Similarly, type C_PTR can be used in a dummy argument or structure component and can have a value that is the C address of a procedure or allocatable variable, even in contexts where a procedure or allocatable variable is not directly allowed." The following two edits per John. 374:5. Change first sentence to 'A C procedure argument is often defined in terms of a <>'. [We clearly need the term.] 374:7,9. Change '"C address"' to 'C address'. 372:26+ Move 15.2.3 (after above 2 edits) to here, changing heading to "15.1.2 Procedures in the module" Simplify long lists of names along lines suggested in 02-136 [371:13-17] Replace "C_INT...C_BOOL" with "named constants with the names listed in the second column of Table 15.1" [371:19-2] Replace "C_INT...C_CHAR" with "listed in the second column of table 15.1" Per John, 372:2,4. Move 'C_SIGNED_CHAR' up to follow 'C_LONG_LONG'. 372:16. Move line to follow NOTE 15.2. Subclause 15.2 is where we define the term interoperability in all its forms. Material that does anything other than define that term doesn't belong here (notably 15.2.3 and 15.2.7). We also strengthen the organization by clearly separating the treatment of types from the treatment of data entities. 372:27 Change "Interoperation" to "Interoperability" Be more general here. [372:27+] Insert \begin{jnote} Need to clarify what it means for something to be just plain interoperable (as opposed to interoberable with something in particular). \end{jnote} 372:28 "a variable...procedure." -> "a Fortran entity" and less wordy 372:29 "an entity in a C program" -> "a C entity" 372:29 "entity in the Fortran program" -> "Fortran entity" 373:1 Change heading to "Interoperability of intrinsic types" Move Note 15.4 to [377:2-] at the end of the subclause on arrays. Also insert the xref "Note 15.18" at the beginning of the last line of Note 15.4. Remove discussion of entities of these types; this is just about the types (and type parameters) themselves. 373:2-11 Replace this para with "Table 15.1 shows the interoperability between Fortran intrinsic types and C types. A Fortran intrinsic type with particular type parameter values is interoperable with a C type if the type and kind type parameter value are listed in the table on the same row as that C type and the kind type parameter value is positive; if the type is character, interoperability also requires that the length type parameter be omitted or be specified by an initialization expression whose value is one. A combination of Fortran type and type parameters that is interoperable with a C type listed in the table is also interoperable with any unqualified C type that is compatible with the listed C type. The second column of the table refers to the named constants made accessible by the ISO_C_BINDING intrinsic module. If the value of any of the kind type parameters in the table is negative, there is no combination of Fortran type and type parameters interoperable with the C type shown in that row." Table 15.1 - In title change "Correspondence" -> "Interoperability" In note 15.5, "a scalar object of type" -> "the type" "a scalar object of the C type" -> "the C type" "or of" -> "or" In note 15.6, delete "a scalar of"; "scalars of" -> "the". Per John 374:NOTE 15.6, lines 4-5. Change 'C_UNSIGNED_INT, ... C_UNSIGNED_CHAR' to 'for their kind type parameter values'. [As far as I can see, these names are not defined.] [374:1] Change "Interoperation" -> "Interoperability" [374:2-3] Replace para with "C_PTR shall be a derived type with private components or shall be a type alias name. It is interoperable with any C pointer type." Note 15.8. Delete this note. (It is no longer true). [375:18] Change "Interoperation" -> "Interoperability" [375:19-20] "A scalar Fortran...C entity of a" -> "A Fortran derived type is interoperable with a C" [375:22] "are interoperable with" -> "have types and type parameters that are interoperable with the types of" [376:1] "Fortran entity" -> "Fortran type" delete "entity of a". [376:2:3] "Fortran entity" -> "Fortran type" delete "entity of a". Note 15.11 First sentence "a scalar C object of type" -> "the C type" "a scalar Fortran object of type" -> "the Fortran type" Note 15.11 Last line "entities of a derived type are" -> "a Fortran derived type is" "entities of a C" -> "a C" Note 15.12 - Delete "entity of" twice. [376:4-] Insert new subclause "15.2.x Interoperability of scalars" A scalar Fortran data entity is interoperable with a scalar C entity if their types and type parameters are interoperable, the Fortran entity is not polymorphic, and the Fortran entity has neither the pointer nor the allocatable attribute. [376:4] Change heading to "Interoperability of arrays" [377] Add a new note after Note 15.13 "A polymorphic, allocatable, or pointer array is never interoperable. Such arrays are not explicit shape or assumed size." [377:2] Change heading to "Interoperability of procedure interfaces" 377: Issue 342 - delete the issue. [377:8-9] "compatable with the C type" -> "of" (It is claimed that no type other than void meets the previous criterion anyway - I wouldn't know). We want interoperability of the entities, not just the types. This covers the type parameters and excludes polymorphics, pointers, and allocatables. We did talk about entities for the VALUE case. [378:4] Delete "type of the" [378:5] insert "an entity of" after "with" Consolidate requirements specified in random other places to here. [377:6] insert "a scalar that is" before "interoperable". [377:12] insert "nonoptional" after "are". Subclause 15.2.7 does not define interoperability and thus doesn't belong under 15.2. It defines linkage of global variables. Also, we've already defined what it means for a variable to be interoperable. This subclause is about making things actually interoperate - not just be interoperable. [379:1] Raise heading a level to 15.3. [379:2-3] swap the last two "with" clauses in the first sentence of the subclause (to avoid the parsing ambiguity that clearly confused John). [379:3,9-10] "is interoperable" -> "interoperates" (twice) This subclause perhaps could use further work, but this will do for now. [380:1] Raise heading one level to 15.3.1 (We shouldn't have a .1 without a .2 in any case, but I'll defer that. Part of general deferred fixups here.) [380:11+] Add a new subclause as follows: "15.4 Interoperation with C functions A procedure with the BIND attribute shall have an interface that is interoperable. The procedure may be defined either (1) by means other than Fortran or (2) by means of a Fortran subprogram that has a in its or , \begin{jnote} Work on ENTRY statements is needed. Do we allow mixing BIND(C) and non-BIND(C) procedures in the same subprogram? Old words made all entries implicitly BIND(C) if the subroutine/function statement was, but did nothing to prohibit BIND(C) entries after non-BIND(C) subroutine/function statements. That seems odd. Current words allow arbitrary mixing, which needs a few words added above, but is objected to by some. Another proposal is to prohibit any form of mixing and require BIND(C) to be explicit, which would require a constraint in the entry statement, and which would probably mean the above words are ok. \end{jnote} but not both. If the procedure is defined by means other than Fortran, it shall (1) be describable by a C prototype that is interoperable with the interface, (2) have external linkage as defined by 6.2.2 of the C standard, and (3) have the same binding label as the interface. A reference to a procedure that has the BIND attribute and is defined by means other than Fortran causes the C function to be called as specified in the C standard. 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." Move the para from [271:8-11] to here, after deleting "then" from [271:9]. Move 12.5.2.7 to here as 15.4.1. Annex C typos [457:2,7,42] remove "}" at line end. Issue 346 (all copied as is from 02-136) 266:NOTE 12.41. Add to first use statement: ', ONLY: C_INT, C_FLOAT 371: Delete issue 346 375:NOTE 15.9. Change the first use statement: USE ISO_C_BINDING, ONLY: C_PTR, C_FLOAT, C_ASSOCIATED, C_LOC 379:Note 15.18, first line. Fix spelling of "interoperability." 379:NOTE 15.18. Change the first use statement: USE ISO_C_BINDING, ONLY: C_CHAR, C_NULL_CHAR [457:34] Change to "USE ISO_C_BINDING, ONLY: C_INT, C_FLOAT, C_LOC"