To: J3 12-120r1 From: Bill Long Subject: TS 29113: Changes made to N1885 to create N1904 Date: 2012 February 16 References: WG5/N1885, WG5/N1890, WG5/N1895 The goal of this paper is to produce a final version of WG5/N1905 that documents the changes made to the initial DTS draft. ------------------------------------------------------- ISO/IEC JTC1/SC22/WG5 N1905 Changes to N1885 to create N1904 Bill Long WG5 document N1885 was the initial candidate DTS for TS 29113, Further Interoperability of Fortran with C. An informal WG5 Ballot, N1890, resulted in comments documented in N1895. Those Ballot comments and additional comments resulting from email discussions on the interop-tr email list and the j3 email list resulted in comments included in this document. Additional changes included arose from these papers passed at J3 meeting 197: J3/12-111r2 J3/12-123r2 J3/12-130r2 J3/12-137r1 The accumulation of these changes applied to N1885 resulted in an updated DTS candidate document WG5/N1904. Edit citations refer to N1885. The comments are divided into two groups: I) Comments that resulted in changes II) Comments that did not result in changes Comments include either a J3 paper number or the name of the commenter and source of the comment. The commenters are: Bill: Bill Long, Cray Inc. (USA) (TS editor) John: John Reid, RAL (UK) (WG5 Convener) Malcolm: Malcolm Cohen, NAG (UK) (Fortran standard editor) Reinhold: Reinhold Bader, LRZ (Germany) Robert: Robert Corbett, Oracle (USA) Van: Van Snyder, NASA/JPL (USA) Some comments include explanatory text enclosed in { }. ------------------------------------------------------------ I) Comments that resulted in changes: ===================================== 1) Van: (22-oct-2011 email) In Foreword p4 "accepted" should be "accepted". ------------- 2) Bill: (Editorial) In Foreword, final para, change "29113:2011" to "29113:2012". ------------- 3) Bill (Editorial) 5.1 Assumed-type objects, move the sentence "An assumed-type object is unlimited polymorphic." from just before Note 5.1 to the end of the paragraph just before constraint C407a. ------------- 4) Van: (24-oct-2011 email, Ballot comment 1 of 26 from N1895) 5.1p3 Note 5.2: Replace "within Fortran code" by "for a Fortran procedure". ------------ 5) Bill: (Editorial) 5.2 Assumed-rank objects, in Note 5.3, last sentence, replace "must" with "should". {Use of "must" is discouraged, even in Notes.} ------------ 6) Robert: (Ballot comment 1 of 3 from N1895 [partial]) John: (23-jan-2012 email), Malcolm (25-jan-2012 email) 5.4.1: delete "initiated ... C" {Potentially conflicts with "defined by means other than Fortran" in 5.4.2p1. Addresses first para of Ballot comment 1.} ------------ 7) John: (26-jan-2012 email, Ballot comment 1 of 6 from N1895) 6.3 Argument association: Replace the third sentence of para 1, "If the actual argument is an array ... assumed from the actual argument." with "If the actual argument is an array, the rank and extents of the dummy argument are assumed from the actual argument, including the lack of a final extent in the case of an assumed-size array. If the actual argument is an array and the dummy argument is allocatable or a pointer, the bounds of the dummy argument are assumed from the actual argument." {The bounds are assumed only for the allocatable and pointer cases.} And, delete the fourth sentence of para 1. "The values of the lower ... specified." {In the allocatable and pointer cases, the sentence does not say anything. For the other cases, the sentence contradicts the convention of setting the lower bound to zero.} {The final wording of the edits varies from those suggested in the original ballot comment.} ------------ 8) Van: (12-137r1) [6.3p3] "If" should be "When" ------------ 9) Bill: (Editorial), Malcolm: (23-jan-2012 email) 6.4 Intrinsic procedures: In 6.4.1 Shape, line 3 change "a value of" to "a value equal to". In 6.4.2 Size, lines 2 and 5, change "a value of" to "the value" twice. In 6.4.3 Ubound, line 3 change "a value of" to "a value equal to". {Change wording to match style of F2008 intrinsic descriptions. The edits in 9.8 do not use "a value of", so no changes there.} ------------ 10) Van: (24-oct-2011 email, Ballot comment 5 of 26 from N1895) 6.4.3p1: After "result" insert "of UBOUND(ARRAY,RANK(ARRAY),[KIND])". {The array constructor brackets, [ ], around KIND were removed and spacing added to match the style of the LBOUND ref later in the sentence.} ----------- 11) Bill: (12-130r2) In 7.2 RANK, The example does not really make clear why this function is needed. Replacing the existing sentence by "If X is a dummy argument declared with REAL X(..) and is argument associated with an effective argument that was declared REAL Y(:,:,:), RANK(X) has the value 3." ----------- 12) Van: (21-oct-2011 email) In 8.1p1 and 8.1p2, "must" ought to be "shall". ----------- 13) Bill (12-111r2) In the title for 8.1, replace "C_F_POINTER, ... C_FUNLOC" by "ISO_C_BINDING module procedures" ----------- 14) Bill: (12-111r2) In 8.1 after paragraph 1 add new paragraph: "The function C_F_PROCPOINTER from the intrinsic module ISO_C_BINDING has the restriction in ISO/IEC 1539-1:2010 that CPTR and FPTR shall not be the C address and interface of a noninteroperable Fortran procedure." ----------- 15) Bill: (12-111r2) In 8.1 after the final paragraph add a new paragraph: "If the value of a C function pointer will be the result of a reference to C_FUNLOC with a noninteroperable argument, it is recommended that the C function pointer be declared with a prototype of \cf{void (*funptr_name)()}." ----------- 16) John: (26-jan-2012 email) 8.2 C descriptors: Replace the second sentence "The C descriptor ... a C function." with "The C descriptor along with library functions with standard prototypes provides the means for describing within a C function an allocatable or data pointer object, a nonallocatable nonpointer data object of known shape, or an assumed-size array." ----------- 17) Bill: (12-123r2; partly replaces edit above) 8.2 C descriptors: In the second sentence, change "a nonallocatable nonpointer data object of known shape, or an assumed-size array" to "or a nonallocatable nonpointer object that is scalar or is an assumed-shape, explicit-shape, or assumed-size array". {The term "known shape" is not defined and the list of alternatives using defined terms is short. Ed: Corrected the edit from the paper, which had an extra "array of" before "assumed-shape".} ----------- 18) Van: (12-137r1) [8.3.1] Sometimes "ISO_Fortran_binding.h" is a header and sometimes a file. In p1, "file" -> "header file". In p3, "header ISO_Fortran_binding.h" -> "ISO_Fortran_binding.h header file". ----------- 19) John: (28-jan-2012 email) 8.3.2 CFI_dim_t, description of "extent": At the end of the sentence add ", or the value -1 for the final dimension of an assumed-size array". {Allow for the special value for assumed-size final dimension.} ----------- 20) Van: (12-137r1) [8.3.3 "base_addr"] Need a noun after "allocatable". Insert "variable" after "allocatable". ----------- 21) John/Bill: (27-jan-2012 email) 8.3.3: In the description of the attribute member: Replace "allocatable, assumed-shape, assumed-size, or a data pointer" with "allocatable, a data pointer, or a nonallocatable, nonpointer data object". ----------- 22) Bill: (17-jan-2012 email) 8.3.3: In the para following the dim[] description, the current text does not cover all of the possible arrays that are represented by a C descriptor. Replace the current paragraph "For a C descriptor of an assumed-shape...is the Fortran lower bound." with: "For a C descriptor of an array pointer or allocatable array, the value of the lower_bound member of each element of the dim member of the descriptor is determined by argument association, allocation, or pointer association. For a C descriptor of a nonallocatable nonpointer object, the value of the lower_bound member of each element of the dim member of the descriptor is zero." ----------- 23) Bill: (11-dec-2011 email) 8.3.3, last para before Note 8.1, change "-2" to "-1" as the extent member value for an assumed-size array. {Make this consistent with the SIZE modification on page 14.} ----------- 24) Bill/John: (8-jan-2012 email, 26-jan-2012 email) 8.3.4 Macros, in Table 8.1 Macros specifying attribute codes, replace the entry for CFI_attribute_assumed with "CFI_attribute_other nonallocatable nonpointer" {This macro corresponds to more than just assumed-shape arrays. Edit is needed independent of the unknown_size issue.} {Part of edits to remove CFI_attribute_unknown_size} ----------- 25) Bill/John: (8-jan-2012 email) 8.3.4 Macros, in Table 8.1 Macros specifying attribute codes, delete the last entry "CFI_attribute_unknown_size | assumed size". {Part of edits to remove CFI_attribute_unknown_size} ----------- 26) Bill: (Editorial) 8.3.4 Macros, in Table 8.1 Macros, reorder the entries as pointer, allocatable, other. {Matches the order of the descriptions in the following paragraph, and puts "other" last.} ----------- 27) Bill: (26-jan-2012 email) 8.3.4 Macros, in Table 8.1, change the Code for CFI_attribute_pointer from "pointer" to "data pointer". In the following paragraph, in the description of CFI_attribute_pointer, change "an object" to "a data object". ----------- 28) Bill/John: (8-jan-2012 email, 26-jan-2012 email) 8.3.4 Macros, in the para following Table 8.1, replace the last two sentences "CFI_attribute_assumed specifies ... CFI_attribute_unknown_size specifies an object that is, or is argument associated with, an assumed-size dummy argument." with "CFI_attribute_other specifies an assumed-shape array, a nonallocatable nonpointer scalar, an assumed-size array, or an array that is argument associated with an assumed-size array." {Part of edits to remove CFI_attribute_unknown_size} ------------ 29) Bill: (12-123r2, replaces the edit above) 8.3.4 Macros, in the paragraph following Table 8.1: In the second sentence change "CFI_attribute_other specifies an assumed-shape array, a nonallocatable nonpointer scalar, an assumed-size array, or an array that is argument associated with an assumed-size array." to "CFI_attribute_other specifies a nonallocatable nonpointer object that is scalar or is an assumed-shape, explicit-shape, or assumed-size array." {If the C descriptor corresponds to a Fortran interface dummy that is assumed-shape and the corresponding actual argument is explicit-shape, the C descriptor actually describes the actual argument. Should make the wording here and in subclause 8.2 similar.} ------------ 30) Robert: (Ballot comment 3 of 3 from N1895) 8.3.4 Macros I agree with Van that a macro for an attribute code for scalars should be included in Table 8.1. If no such macro is provided, then the TS should state how scalars are to be handled. Bill said that a scalar should be given the attribute code CFI_attribute_unknown_size. The only way I see to derive that information from the existing text is by elimination. {The new collection of attribute codes allow description of a scalar that is allocatable (CFI_attribute_allocatable), a pointer (CFI_attribute_pointer), or neither allocatable nor pointer (CFI_attribute_other). No additional edit for this comment.} ------------ 31) Van: (24-oct-2011 email, Ballot comment 6 of 26 from N1895) 8.3.4p6: It's not obvious what attribute code an assumed-length character scalar. CFI_attribute_assumed is probably the correct one, but (if so) the description ought to say so. {CFI_attribute_assumed was replaced by CFI_attribute_other which can be used to describe a scalar. With this change, any of allocatable, pointer, or other attributes can describe a scalar. No additional edit for this comment.} ---------- 32) Bill/Van (18-jan-2012 email) 8.3.5.1 General (at the beginning of the function descriptions): Add a new paragraph after para1 "In function arguments representing subscripts, bounds, extents, or strides, the ordering of the elements is the same as the ordering of the elements of the dim member of a C descriptor." {Subsumes several comments on the ordering of elements.} ------------- 33) Van: (24-oct-2011 email, Ballot comment 8 of 26 from N1895) 8.3.5.2p2, description of "subscripts": Is the order of subscripts the Fortran order or the C order? {Incorporated into the edit for 8.3.5.1.} ---------- 34) Van: (24-oct-2011 email, Ballot comment 7 of 26 from N1895) 8.3.5.2p3: The symbol $r$ appears without explanation. After "array" insert "of rank $r$". ----------- 35) Van: (24-oct-2011 email, Ballot comment 9 of 26 from N1895) 8.3.5.2p5: The example would be more informative if the subscripts were different. Inquiring minds might realize that Fortran and C subscripts have opposite ordering, and wonder which order they ought to appear in the subscripts array. {Changed element (10,10) -> (5,10). Also changed subscripts[0] value to 4.} ----------- 36) Van: (24-oct-2011 email, Ballot comment 10 of 26 from N1895) 8.3.5.3p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "Allocates" with "Allocate". ------------- 37) Van: (24-oct-2011 email, Ballot comment 11 of 26 from N1895) 8.3.5.3p2, descriptions of "lower_bounds" and "upper_bounds": Is the order of elements in the arrays the order of C array bounds or Fortran array bounds? {Incorporated into the edit for 8.3.5.1.} ------------ 38) Bill: (6-jan-2012 email) and John: (10-jan-2012 email) 8.3.5.3 CFI_allocate: para following "elem_len" description: Replace "CFI_allocate allocates memory" with "Successful execution of CFI_allocate allocates memory". Before the last sentence of the paragraph, insert a new sentence "The supplied lower and upper bounds override any current dimension information in the C descriptor.". At the end of the paragraph add "If the type specified in the C descriptor is a character type, the supplied element length overrides the current element-length information in the descriptor." {Last sentence was moved and reworded from the original comment.} para before "Result Value": Delete the first sentence "On successful execution...". ------------- 39) Van: (24-oct-2011 email, Ballot comment 12 of 26 from N1895) 8.3.5.3p4: Is dv->elem_len updated if no error is detected? Need to add a sentence saying that the member is updated in the case of a character type, and not updated otherwise. {Sentence added as part of the previous edit.} ------------ 40) Van: (24-oct-2011 email, Ballot comment 13 of 26 from N1895) 8.3.5.3p7: The example would be more informative if the bounds were different. Inquiring minds might realize that Fortran and C bounds have opposite ordering, and wonder which order they ought to appear in the lower and upper arrays. {The upper bounds actually are different: 100 and 1000. However, these might be misread, so changed 1000 to 500 twice.} ------------ 41) Van: (24-oct-2011 email, Ballot comment 14 of 26 from N1895) 8.3.5.4p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "Deallocates" with "Deallocate". ----------- 42) Bill: (6-jan-2012 email) 8.3.5.4 CFI_deallocate: para following the "dv" description: Replace the whole paragraph with "Successful execution of CFI_deallocate deallocates memory for the object using the same mechanism as the Fortran DEALLOCATE statement. The base_addr member of the C descriptor becomes a null pointer." {This now parallels the wording used in CFI_allocate.} para before "Result Value": Delete the first sentence "On successful execution...". ------------ 43) Van: (24-oct-2011 email, Ballot comment 15 of 26 from N1895) 8.3.5.5p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "Establishes" with "Establish". ------------ 44) Bill: (26-jan-2012 email) 8.3.5.5 CFI_establish, description of "attribute" formal parameter, change "CFI_attribute_assumed, CFI_attribute_allocatable, or CFI_attribute_pointer" to "the attribute codes in Table 8.1". {With the revised attribute codes, all are valid here.} ------------ 45) Van: (24-oct-2011 email, Ballot comment 17 of 26 from N1895) 8.3.5.5p2, description of "extents": Is the order of extents the Fortran order or the C order? {Incorporated into the edit for 8.3.5.1.} ------------ 46) John: (26-jan-2012 email) 8.3.5.5: In the para following the extents para: I believe that the omission of the assumed-size case is deliberate. Let's cement this by adding "These extents shall all be nonnegative." at the end of the extents paragraph. ------------ 47) Bill: (6-jan-2012 email) 8.3.5.5 CFI_establish: para following the "extents" description: Replace "CFI_establish establishes a C descriptor for an assumed-shape" with "Successful execution of CFI_establish updates the object with the address dv to be an established C descriptor for an assumed-shape". para before "Result Value": Replace the paragraph with "If an error is detected, the object with the address dv is not modified." ------------ 48) John: (26-jan-2012 email) 8.3.5.5: I think a change is needed in the para. following the extents para. The words "an assumed-shape array, an assumed character length object" should be "a nonallocatable nonpointer data object of known shape". {Ed: Also, before the subsequent text "unallocated allocatable" insert "an ".} ------------ 49) Bill: (26-jan-2012 email) 8.3.5.5 CFI_establish: para following the "extents" description: change "CFI_attribute_assumed" to "CFI_attribute_other". {Attribute renamed.} ------------ 50) Reinhold: (Ballot comment 6 of 6 from N1895) 8.3.5.5 CFI_establish, para following the argument descriptions: italicize "attribute" in "; if the attribute argument ..." {Modified to use code font rather than italics to match the convention for source text.} ------------ 51) Bill: (12-130r2) In 8.3.5.5 CFI_establish, in the paragraph following the extents description, in the penultimate sentence change "... but does not describe a Fortran assumed-shape array". to "... but does not describe a data object." {Objects other that assumed-shape arrays are included in the list of things not described.} ------------ 52) Bill: (26-jan-2012 email) 8.3.5.5 CFI_establish: In Note 8.8 change "CFI_attribute_assumed" to "CFI_attribute_other". {Attribute renamed.} ----------- 53) John: (29-jan-2102 email) 8.3.5.5 CFI_establish: In Note 8.8 change "Fortran assumed-shape array" to "nonallocatable nonpointer data object". {Results other than assumed-shape arrays are allowed.} ----------- 54) Bill: (26-jan-2012 email) 8.3.5.5 CFI_establish: In the last code statement of Example 2 change "CFI_attribute_assumed" to "CFI_attribute_other". {Attribute renamed.} ------------ 55) John: (11-jan-2012 email) 8.3.5.6 CFI_is_contiguous, replace the body of Note 8.10 with: "A C descriptor for an array describes a contiguous object if it has extent -1 in its final dim element or if its attribute member indicates that the array is allocatable." {Part of edits to remove CFI_attribute_unknown_size} ------------ 56) Van: (24-oct-2011 email, Ballot comment 18 of 26 from N1895) 8.3.5.7p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "Updates" with "Update". ------------ 57) Bill: (26-jan-2012 email) 8.3.5.5 CFI_section: In the description of the "result" formal parameter, change "CFI_attribute_assumed" to "CFI_attribute_other". {Attribute renamed.} ------------ 58) Bill: (27-jan-2012 email) John: (19-jan-2012 email) Van: (12-137r1) 8.3.5.7p2, description of the source member, change "an assumed-shape array" to "a nonallocatable nonpointer array". {The C descriptor could be describing an explicit-shape array.} ------------ 59) Van: (24-oct-2011 email, Ballot comment 19 of 26 from N1895) 8.3.5.7p2, description of "lower_bounds" and "upper_bounds": Is the order of elements in the arrays the order of C array bounds or Fortran array bounds? What is "the given array?" Should this be "the array described by the descriptor dv?" Is it OK for the number of elements to be > source->rank? {Ordering issue incorporated into the edit for 8.3.5.1.} {The "given array" is the "array described by the C descriptor with the address source", using the same phrasing as in the description for the strides formal parameter. Make this change for both lower_bounds and upper_bounds.} {Change "shall be source->rank" to "shall be greater than or equal to source->rank" for both lower_bounds and upper_bounds.} ------------ 60) John: (28-jan-2012 email) 8.3.5.7 CFI_section, descriptions of lower and upper bounds: 8.3.5.7, lower_bounds para. Change "element of " to "element of the array described by the C descriptor with the address ". 8.3.5.7, upper_bounds para. Change "element of " to "element of the array". 8.3.5.7, upper_bounds para. After "If it is a null pointer," add "the C descriptor with the address shall not describe an assumed-size array and" {Allow an assumed-size array as the source.} ------------ 61) Van: (24-oct-2011 email, Ballot comment 20 of 26 from N1895) 8.3.5.7p2, description of "strides": Is the order of elements in the array the order of C array bounds or Fortran array bounds? Is it OK for the number of elements to be > source->rank? {Ordering issue incorporated into the edit for 8.3.5.1.} {Change "shall be source->rank" to "shall be greater than or equal to source->rank" in the description of extents.} ------------ 62) Bill: (6-jan-2012 email) John: (10-jan-2012 email and Ballot comment 3 of 6 from N1895) 8.3.5.7 CFI_section: para following the "strides" description: Replace "CFI_section updates" with "Successful execution of CFI_section updates the base_addr and dim members of". {Modified to remove [] after dim.} para before "Result Value": Replace the paragraph with "If an error is detected, the C descriptor with the address result is not modified." ----------- 63) Bill: (26-jan-2012 email) 8.3.5.7 CFI_section: In Example 1 reference to CFI_establish, change "CFI_attribute_assumed" to "CFI_attribute_other". {Attribute renamed.} ------------ 64) Bill: (26-jan-2012 email) 8.3.5.7 CFI_section: In Example 2 reference to CFI_establish, change "CFI_attribute_assumed" to "CFI_attribute_other". {Attribute renamed.} ------------ 65) Van: (24-oct-2011 email, Ballot comment 21 of 26 from N1895) 8.3.5.8p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "CFI_select part updates" with "Update". ------------ 66) Bill: (26-jan-2012 email) 8.3.5.8 CFI_select_part: In the description of the "result" formal parameter, change "CFI_attribute_assumed" to "CFI_attribute_other". {Attribute renamed.} ------------ 67) Bill: (30-jan-2012 email) Van: (12-137r1) 8.3.5.8 CFI_select_part: In the description of the "source" formal parameter, change "an assumed-shape" to "a nonallocatable nonpointer". {The new CFI_attribute_other might be describing an array that is not assumed-shape.} ------------ 68) Bill: (6-jan-2012 email) John: (Ballot comment 4 of 5 from N1895) 8.3.5.8 CFI_select_part para following "elem_len" description: Replace "CFI_select_part updates" with "Successful execution of CFI_select_part updates the base_addr, dim, and elem_len members of". {Modified to remove [] after dim.} para before "Result Value": Replace the paragraph with "If an error is detected, the C descriptor with the address result is not modified." ------------ 69) Bill: (26-jan-2012 email) 8.3.5.8 CFI_select_part In the Example code, in the reference to CFI_establish, change "CFI_attribute_assumed" to "CFI_attribute_other". {Attribute renamed.} ------------ 70) Van: (24-oct-2011 email, Ballot comment 23 of 26 from N1895) 8.3.5.9p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "CFI_setpointer part updates" with "Update". {There was no "part". Replaced "CFI_setpointer updates" with "Update".} ------------ 71) Bill: (27-jan-2012 email) John: (19-jan-2012 email) 8.3.5.9 CFI_setpointer, source description, replace "assumed-shape array" with "nonallocatable nonpointer data object". {The target could be a scalar which is not "assumed-shape".} ------------ 72) Bill: (6-jan-2012 email) John: (Ballot comment 5 of 6 from N1895) 8.3.5.9 CFI_setpointer para following the "lower_bounds" description: Replace "CFI_setpointer updates" with "Successful execution of CFI_setpointer updates the base_addr and dim members of". {Modified to remove [] from dim.} para before "Result Value": Replace the paragraph with "If an error is detected, the C descriptor with the address result is not modified." ------------ 73) Van: (12-137r1) [8.3.5.9 "Example"] Insert "be" before the second "a C descriptor". ------------ 74) Reinhold: (18-jan-2012 email): 8.3.6 - 8.3.9: Rename subsections 8.3.6-8.3.9 to 8.4-8.7 since the topic of these is not anything in ISO_Fortran_binding.h. {Additional edits in 9.9 to fix references.} ------------ 75) John: (6-jan-2012 email) 8.3.6: While working on the edits for unknown_size, I noticed an incorrect use of 'it' in the bullet list in 8.3.6. I suggest these edits: bullet 1. Change 'it' to 'the C descriptor'. bullet 2. Change 'its base_addr member' to 'the base_addr member of the C descriptor'. ------------ 76) Bill: (Editorial) 8.3.6: Use of C descriptors, in the first bullet change "an assumed-shape or assumed-size object" to "a nonallocatable nonpointer object". {Part of the edits needed for the new attributes.} ------------ 77) Van: (24-oct-2011 email, Ballot comment 24 of 26 from N1895) 8.3.8p5 Note 8.12: "bind(c)" should be "bind(c,name='Cfun')", or "Cfun" in the narrative should be "cfun". {Selected the first option.} ------------ 78) John: (26-jan-2012 email) 8.3.9 para 5, Replace the beginning of the sentence "If a dummy argument in an interoperable interface is allocatable...or a pointer" with "If a dummy argument in an interoperable interface is allocatable, assumed-shape, of assumed character length, assumed-rank, or a data pointer" ------------ 79) Bill: (12-130r2) In 8.6 Restrictions on lifetimes, paragraph 2, last sentence, change "object it describes" to " object described by the C descriptor". {Clarify "it".} ------------ 80) Bill: (12-130r2) In 8.7 Interoperability of procedures and procedure interfaces, paragraph 5, second sentence (top of page 31) change: "The C descriptor shall describe an object with the same characteristics as the effective argument; the type member" to "The value of the \cf{attribute} member of the C descriptor shall be compatible with the characteristics of the dummy argument. The members of the C descriptor other than \cf{attribute} and \cf{type} shall describe an object with the same characteristics as the effective argument. The \cf{type} member" {In a call from Fortran to C, the attribute member of a C descriptor pointed to by a formal parameter gets its value from the corresponding dummy argument in the Fortran interface. This is necessary because of cases such as an allocatable actual argument corresponding to an assumed-shape dummy in the interface. The attribute has to be determined by the assumed-shape dummy and not the allocatable actual. The other members in the descriptor get their values from the corresponding effective argument, because the corresponding dummy in the interface could be assumed type or assumed rank. Whether an object is allocatable, pointer, or neither is a characteristic, so the current sentence is misleading.} ------------ 81) Bill: (12-123r2) In 8.7 Interoperability of procedures and procedure interfaces, in the penultimate para change "corresponding actual" to "associated effective". {If the actual argument is a pointer, and the effective argument the target of that pointer, the C descriptor describes the effective argument.} ------------ 82) Bill: (12-111r2) In 8.7 Interoperability of procedures ... before the final paragraph, add a new paragraph: "A C function shall not invoke a function pointer whose value is the result of a reference to C_FUNLOC with a noninteroperable argument." ------------ 83) Bill: (12-130r2) In 8.7 Interoperability of procedures and procedure interfaces, in the last paragraph add a sentence: "An absent optional dummy argument in a reference to an interoperable procedure from a C function is indicated by a corresponding argument with the value of a null pointer." {Cover the case of a called procedure in Fortran.} ------------ 84) Bill: (Editorial) 9.2 Edits to Introduction, in line 3 change "29113:2011" to "29133:2012". ------------ 85) Bill: (Editorial) 9.8 Edits to clause 13: In the Example section of the edits for 13.7.137a RANK (A), change "the result has the value 3" to "RANK(X) has the value 3". {Match the style of F2008.} {Edit overridden by the following edit} ------------ 86) Bill: (12-130r2) In 9.8 Edits to clause 13, in the edits for 12.7.137a RANK, Replacing the existing sentence following "Example." with "If X is a dummy argument declared with REAL X(..) and is argument associated with an effective argument that was declared REAL Y(:,:,:), RANK(X) has the value 3." ------------ 87) Bill: (12-130r2) 9.9 Edits for clause 15: In the edit instructions at the beginning of the second edit for 15.3.7, append "after replacing 8.2 in the new text with the Table number for the table "Macros specifying type codes" " ------------ 88) Bill: (12-111r2) 9.9 Edits for clause 15, add: {In 15.2.3.4 C_F_PROCPOINTER, paragraph 3} In the description of argument CPTR, after " that is interoperable" insert "or the result of a reference to C_FUNLOC with a noninteroperable argument". In the description of argument FPTR, replace "The interface for FPTR shall be interoperable with the prototype that describes the target of CPTR." with "If the target of CPTR is interoperable, the interface for FPTR shall be interoperable with the prototype that describes that target. Otherwise, the interface for FPTR shall have the same characteristics as that target." ------------ 89) Bill: (12-130r2) 9.9 Edits for clause 15: In the second edit for 15.3.7, replace the last sentence of the first paragraph "The C descriptor shall describe an object with the same characteristics as the effective argument." with "The value of the \cf{attribute} member of the C descriptor shall be compatible with the characteristics of the dummy argument. The members of the C descriptor other than \cf{attribute} and \cf{type} shall describe an object with the same characteristics as the effective argument. The \cf{type} member shall have a value from Table 8.2 that depends on the effective argument as follows: \begin{itemize} \item if the dynamic type of the effective argument is an interoperable type listed in Table 8.2, the corresponding value for that type; \item if the dynamic type of the effective argument is an intrinsic type with no corresponding type listed in Table 8.2, or a noninteroperable derived type that does not have type parameters, type-bound procedures, final procedures, nor components that have the ALLOCATABLE or POINTER attributes, or correspond to CFI_type_other, one of the processor-dependent nonnegative type specifier values; \item otherwise, CFI_type_other. \end{itemize}" ------------ 90) Bill: (missing edit in 12-123r2) 9.9 In the second edit for 15.3.7, paragraph 2, line 2, change "corresponding actual" to "associated effective". ------------ 91) Bill: (12-130r2) 9.9 In the second edit for 15.3.7, at the end of the last paragraph add a sentence: "An absent optional dummy argument in a reference to an interoperable procedure from a C function is indicated by a corresponding argument with the value of a null pointer." ------------ 92) Bill: (Editorial and 12-111r2) 9.9 edit beginning "{Before subclause 15.5}" In line 1 change "subclause " to "subclauses " twice, change "8.3" to "8.3 to 8.6", change "15.5" to "15.5 to 15.8", change "8.3.9" to "8.3.5" In line 2 change "15.5.9" to "15.5.5", change "15.6" to "15.9". {Changes required because of renumbering sections 8.3.6-8.3.9.} 9.9 last edit: Change "15.6.4" to "15.10.4". ------------ 93) Bill: (12-111r2) 9.9 Edits to Clause 15, edit for 15.5.1 paragraph 4, after "A C function shall not invoke a" replace "Fortran ... interoperable" with "a function pointer whose value is the result of a reference to C_FUNLOC with a noninteroperable argument." ------------ 94) Bill: (12-111r2) 9.9 Edits to Clause 15: {At the end of 15.5.1 Definition and reference of interoperable procedures, insert a new paragraph:} "If the value of a C function pointer will be the result of a reference to C_FUNLOC with a noninteroperable argument, it is recommended that the C function pointer be declared with a prototype of \cf{void (*funptr_name)()}." ------------ 95) Van: (24-oct-2011 email, Ballot comment 26 of 26 from N1895) 9.11p1: Values specified by attribute macros should be in the list. {inserted before the entry for type specifiers} ------------ 96) Bill: (26-jan-2012 email) A.2.3 Changing the attributes of an array, intro para, change "CFI_attribute_assumed" to "CFI_attribute_other". Same change in the second reference to CFI_establish. {Attribute renamed.} ------------ 97) Bill: (26-jan-2012 email) A.2.4 Creating an array section in C using CFI_section, change "CFI_attribute_assumed" to "CFI_attribute_other" twice, once in each reference to CFI_establish. {Attribute renamed.} ------------ 98) Reinhold: (Ballot comment 1 of 6 from N1895) A.2.6p1: replace "has several functions" by "includes procedures" {Modified. The MPI spec does use the word "procedures", so that's OK. The current wording says that MPI "has" functions. Actually, the library has functions. Since "functions" is plural, it implies more than one, so I'm fine with deleting the "several". Final edit: replace "has several functions" by "specifies procedures".} ------------ 99) Reinhold: (Ballot comment 2 of 6 from N1895) A.2.6p1: after "is similar to the", insert "second variant of" delete "; however it uses assumed rank ... than assumed size" ------------ 100) Reinhold: (Ballot comment 3 of 6, part 2, from N1895) A.2.6p2 (after the C prototype for MPI_send_f):delete "be" in "is also be done" ------------ 101) Reinhold: {Ballot comment 4 of 6 from N1895) A.2.6p4 (after the C prototype for MPI_Comm_set_name_f): replace "can be defined in the module," by "are assumed to be defined in a module". {I agree that this sentence can be improved. To say that the interfaces "can be defined" seems trite since the following text does just that. Similarly, saying they are "assumed to be defined" is unnecessary. Modified to say "are defined in the module MPI_f08".} ------------ 102) Reinhold: (Ballot comment 5 of 6 from N1895) : Three quoting methods are used in N1885 for the binding labels in BIND(C, name=...) statements. It is suggested to use the double quote (") everywhere (although admittedly the standard itself is not entirely consistent here). {Modified to also use " as delimiters for other character strings that are part of display code.} 2) Comments that did not result in a change: ============================================ 103) Van (22-oct-2011 email) Forward p6 in N1885 says "Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights." Should "may" be "might," or does ISO require this non-ISO-ese sentence? {No action. This exact wording is required in Annex F of the ISO rules.} ------------ 104) Robert: (Ballot comment 1 of 3 from N1895 [remainder]) 5.4 ASYNCHRONOUS attribute My greatest concern is still Clause 5.4. A small point first. Clause 5.4.1 states that asynchronous communication is initiated and completed by procedures written in C. Clause 5.4.2 states that asynchronous communications occurs through the action of procedures "defined by means other than Fortran." Those statements are not equivalent. Furthermore, both statements exclude an important possibility, namely that a Fortran processor might provide nonstandard intrinsic procedures that perform asynchronous communications. The statement in paragraph one of Clause 5.4.2 that whether a procedure is an asynchronous communication initiation or completion procedure is "processor dependent" might be misleading. Malcolm asserted that a procedure either is or is not an asynchronous communication procedure is determined by the procedure. Until I saw Malcolm's e-mail, I thought the draft TS meant that the processor would recognize a set of routines as asynchronous communication procedures. Malcolm's interpretation makes more sense, but the current text seems ambiguous. I would like the "processor dependent" statement to be replaced by language that says that an asynchronous communication procedure is one that initiates and/or completes asynchronous communication. My last concern is that the text in the draft TS does not address the impact of Clause 5.4 on processors. Bill said that the Fortran 2008 standard does not address the impact of asynchronous I/O on processors. I concede that the normative text of the standard does not (and I consider that a defect), but Clause C.6.6 does describe the intended effect. If the normative text of the TS does not address the intended impact of asynchronous communications procedures, a note similar to C.6.6 should be provided for asynchronous communications procedures. I would like definitions of asynchronous initiation procedures and asynchronous completion procedures to be added to Clause 3 "Terms and definitions." ------------ 105) Van: (24-oct-2011 email, Ballot comment 2 of 26 from N1895) 5.4.2p1: It seems to be OK for a processor to decide that pure real function xyz ( x ) integer, intent(in) :: x xyz = x + 1.0 end function xyz is an asynchronous communication initiation or completion procedure. {There are no edits proposed.} ------------ 106) Van: (24-oct-2011 email, Ballot comment 3 of 26 from N1895) 6.3p1: With the being there's no place to write explicit lower bounds. Therefore, all elements of the LBOUND result would be 1. The last sentence ought to be something like "The value of the lower bound of each dimension of the dummy argument is 1, and the value of the upper bound of dimension N of the dummy argument is equal to the result of applying the SIZE intrinsic inquiry function to the actual argument with DIM=N specified." {I'm concerned about putting the fact that the default return value for LBOUND() is 1 here in addition to in the description of LBOUND(). If the definition of LBOUND does not say this value is 1, the definition of LBOUND() should be fixed. Change not made.} ------------ 107) Van: (24-oct-2011 email, Ballot comment 4 of 26 from N1895) 6.4.1p1: I don't understand how the expression can work. {It seems OK to me. Suppose you have real :: a(10,20,*) call sub(a) ! where the interface for sub has the corresponding dummy DUM as assumed-rank then RANK(DUM) is 3 and SHAPE(DUM) is [10,20,-1]. The value of SIZE for DIM=3 is specified in 6.4.2 SIZE. SIZE(DUM,DIM=3) is -1. SIZE(DUM) is -200.} ------------- 108) John: (Ballot comment 2 of 6 from N1895) 8.2. In line 2, change "assumed character length, assumed rank" to "assumed size". Reason: See the list of possible attributes in Table 8.1. {The text in this sentence was changed differently to conform with the revised attribute scheme.} ------------ 109) Robert: (Ballot comment 2 of 3 from N1895) 8.3.2 CFI_dim_t I still think the extent field should be an unsigned type, not a signed type. I do not think the definition of CFI_index_t is adequate. I would be satisfied by a note added to the TS explaining that range of values of a CFI_index_t might not include all values of bounds and extents used by a Fortran program. {Making CFI_index_t unsigned would conflict with the convention of specifying the extent = -1 for the last dimension of an assumed-size array.} ------------ 110) Van: (24-oct-2011 email, Ballot comment 16 of 26 from N1895) 8.3.5.5 generally: It's not obvious how to establish an assumed-length character scalar. {No proposed edits. If the descriptor is for a dummy argument (in which case the character length is assumed from the actual in the caller), then the descriptor is already established by the caller. To establish a descriptor to be use later - for example for the result argument in a call to CFI_select_part - based on an incoming argument descriptor named in, then extent[0] = in->dim[0].extent; ind = CFI_establish (result, NULL, in->attribute, in->type, 0, in->rank, extent); To establish a descriptor for use as an actual argument to another function, use CFI_establish with the actual value for elem_len and base_addr if the variable is not an unallocated allocatable. The attribute value would depend on whether the object is intended to be allocatable, pointer, or other (in which case CFI_attribute_other).} ------------ 111) Van: (24-oct-2011 email, Ballot comment 22 of 26 from N1895) 8.3.5.8p2: It's not obvious how (or even if it's possible) to select a substring of a character array. {Suppose you had a descriptor for a Fortran character array with a declaration of character(20) :: string(100) that was passed into a C function via an interface that specified this as an assumed-shape array. The source descriptor in CFI_select_part would look like: base_addr = addr(string(1)(1:1)) elem_len = 20 version = 1 rank = 1 type = CFI_type_char attribute = CFI_attribute_other dim[0].lower_bound = 0 dim[0].extent = 100 dim[0].sm = 20 If you want to create a descriptor for a character section like this: string(:)(3:15) then the arguments to CFI_select_part would be displacement = 2 elem_len = 13 and the fields in the result descriptor would be the same as the ones in the source except for: base_addr = addr(string(1)(3:3)) elem_len = 13 } ------------ 112) Van: (24-oct-2011 email, Ballot comment 25 of 26 from N1895) 8.3.9p2,p3(1): "BIND" should be "BIND(C)" {"BIND" is a duplicate of the text in F2008 [433:5] which is being replaced buy the text in this section. In addition, the name of the attribute is "BIND", not "BIND(C)". I believe the intent of the edit is to better "future-proof" the standard in the event we introduce binding to other languages, such as BIND(UPC). In this context, it is clear that the intent is to have this text to apply only to interoperability with C, and not some other language. The current syntax does include the "(C)" part, although that definition suffers from (in fact, is the source of) the defect in terms of future expansion. The edit is being rejected, leaving the text as it is at [433:5]. This avoids the head scratching for "why did this wording change from the base standard". The general problem that our current syntax is deficient for future expansion is a more widespread issue that should be taken up in the context of the next revision of the base standard.} ------------- 113) John: (Ballot comment 6 of 6 from N1895) 8.3.9, para 5. Change "If a dummy ... actual argument; the" to "In a reference to the C procedure from Fortran, if a formal parameter of the prototype is a pointer to CFI_cdesc_t, the corresponding formal parameter of the reference is interpreted as the address of a C descriptor with the following properties (1) if the dummy argument is allocatable or a pointer, the C descriptor shall describe the actual argument; (2) otherwise, if the dummy argument is assumed rank, the C descriptor shall describe the actual argument as an assumed-shape object; (3) otherwise, if the actual argument is assumed size, the C descriptor shall describe the actual argument; (4) otherwise, if the actual argument is a pointer, the C descriptor shall describe the target of the actual argument as an assumed-shape object; (5) otherwise, the C descriptor shall describe the actual argument as an assumed-shape object. In a reference to the Fortran procedure from C, if a formal parameter of the prototype is a pointer to CFI_cdesc_t, the corresponding argument shall be the address of a C descriptor with the following properties (1) if the dummy argument is of assumed rank or is a nonallocatable, nonpointer variable of type CHARACTER with assumed length, the C descriptor shall describe an assumed-shape object; (2) otherwise, the C descriptor shall describe an object with the properties declared in the Fortran interface for the dummy argument. The" Reason: The present wording is insufficiently precise about which value should be given to the attribute member in the C descriptor. {With the renaming and simplification of the attributes codes, the proposed edits are no longer correct. Further, the new scheme is simple enough that the added description is not needed.} ------------ 114) Reinhold: (Ballot comment 3 of 6, part 1 from N1895) A.2.6p2 (after the C prototype for MPI_send_f): replace "there is a conversion between" by "there exists a conversion facility between" {Change not made. The current text says "...it is assumed that in C there is a conversion between the C handle...". The proposed change is to "...it is assumed that in C there exists a conversion facility between the C handle...". This is a technical change. The current text says that the conversion actually occurs, whereas the replacement says that there is only an existing facility but it is not necessarily used. I believe the intent is that the conversion does actually occur, and the original text is preferred.} ============================