J3/02-245r2 To: J3 From: John Reid Subject: Interoperability edits Date: 24 July 2002, Reviewed by J3 Interop subgroup on 8/13/2002 This is a follow-up to the paper on interoperability (02-188) that I sent to the last meeting. I am, of course, delighted that so many of my suggestions were accepted. I would like to thank Richard Maine for comments on an early draft of this paper. One on my aims in 02-188 was to make it clear that interoperability for a Fortran entity is something that the compiler and the human reader can determine from the Fortran code. I think that J3 accepted this view since it agreed to my edit that now appears on 384:2: 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. However, some of my suggested edits, needed to carry this view through were not passed. I am therefore trying again, but these edits are honed in the light of comments in 02-188r2 and from Richard. 78:2-3. Change to The BIND attribute for a variable or a common block specifies that it is capable of interoperating with a C variable that has external linkage (15.3). [There is a problem in that many interoperable variables will not have the BIND attribute. The BIND sttribute makes a variable global (if it is not already) and adds external linkage. This will usually not be wanted for a variable used as an actual argument in a call to a C procedure and is not allowed if it is itself a dummy argument. The new wording aims to make this clearer to the reader.] 88:5+. Delete internal note. 88:10. Add to the end of C558 'and the entity shall be an interoperable variable (15.2.4, 15.2.5)'. 88:14. Change '15.2' to '15.2.4, 15.2.5'. 88:15. Change 'entities' to 'variables and common blocks'. [I agree with what Richard says in the internal note and would also like to point out that the standard carefully uses different bnf for types (BIND(C), see 42:1), variables and common blocks (language-binding-spec, see 70:7 and 71:33), and procedures (proc-language-binding-spec). This means that the only reasonable interpretation of 5.2.4 is that it applies only to variables and common blocks. My edits make this clear to the reader.] 277:7-8. Change to C1238 (R1225) If proc-language-binding-spec is specified for a procedure, each of the procedure's dummy arguments shall be a nonoptional interoperable variable (15.2.4, 15.2.5) or an interoperable procedure (15.2.6). If proc-language-binding-spec is specified for a function, the function result shall be an interoperable variable. [I did not get this right in 02-188. These are conditions that are buried in the text in 15.2.6 and are better as constraints IMHO, since they are conditions on whether the procedure is ever interoperable.] 282:17-19. Change to If the interface of a procedure has a , the procedure is interoperable (15.4). [The present wording is not consistent with the previous paragraph and suggests that there has to be a corresponding C function.] 386:1+. Add paragraph: A Fortran derived type is <> if it has the BIND attribute. and move lines 8-14 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. [See second paragraph of this paper. Note also that my edits for what is now 387:2-3 and 387:7-8 were accepted.] 388:1+. Add: A Fortran procedure is <> if it has the BIND attribute, that is, if its interface is specified with a . [See second paragraph of this paper.] 388:10-11. Delete. [See constraint at 277:7-8, above.] 390:3-4. Replace the sentence 'A variable ... linkage.' by 'The common block or variable shall be specified to have the BIND attribute.' and start a new paragraph thereafter. [The present sentence is not strong enough and is wrong because it is contradicted by 390:7. A new paragraph is needed to balance the paragaph that starts at line 8.] 391: Last line of note 15.22 Change the curly brace to semicolon ['float single;'] 390:7. Move this line to 14+. [It applies to common blocks, too.] 391:9&11. Change 'extern' to 'external'. 391:13-15. Change to A procedure that is interoperable may be defined either by means other than Fortran or by means of a Fortran subprogram, but not both. and delete the internal note. 391:20-392:1. Change to 'A reference to such a procedure causes the function described by the C prototype to be called as specified in the C standard'. [The present wording makes the reader think that we talking about something different.] 411:27-30. 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 is the C address of any part of 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 is the C address of any part of the variable that is deallocated. [A change here was rejected in 02-188r2 because 'Subgroup believes that association is well-defined for variables of type C_PTR and that no new form of association is introduced'. Perhaps I have missed something, but I have not found the place where it well-defined. All I can find is in the name of C_ASSOCIATED and its informal description.]