To: J3 12-120 From: Bill Long Subject: TS 29113: Changes made to N1885 to create N1904 Date: 2012 January 30 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-xxx J3/12-yyy The accumulation of these changes applied to N1885 resulted in an updated DTS candidate document WG5/N1904. 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) 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". ------------ 4) 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.} ------------ 5) 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.} ------------ 6) 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.} ------------ 7) 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.} ------------ 8) 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.} ----------- 9) Bill: (Editorial) 7.2 RANK, change example to "If X is declared as REAL X(:,:,:), RANK(X) has the value 3." {Change the wording to match the edit in 9.8 and the style of F2008.} ----------- 10) Van: (21-oct-2011 email) In 8.1p1 and 8.1p2, "must" ought to be "shall". ----------- 11) 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." ----------- 12) 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.} ----------- 13) 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". ----------- 14) 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." ----------- 15) 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.} ----------- 16) 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} ----------- 17) 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} ----------- 18) 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.} ----------- 19) 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". ----------- 20) 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} ---------- 21) 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.} ------------- 22) 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.} ---------- 23) 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$". ----------- 24) 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.} ----------- 25) 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". ------------- 26) 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.} ------------ 27) 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...". ------------- 28) 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.} ------------ 29) 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.} ------------ 30) 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". ----------- 31) 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...". ------------ 32) 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". ------------ 33) 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.} ------------ 34) 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.} ------------ 35) 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. ------------ 36) 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." ------------ 37) 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 ".} ------------ 38) 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.} ------------ 39) 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.} ------------ 40) 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.} ----------- 41) 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.} ----------- 42) 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.} ------------ 43) 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} ------------ 44) 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". ------------ 45) 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.} ------------ 46) Bill: (27-jan-2012 email) John: (19-jan-2012 email) 8.3.5.7p2, description of the source member, change "assumed-shape array" to "nonallocatable nonpointer array". {The C descriptor could be describing an explicit-shape array.} ------------ 47) 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.} ------------ 48) 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.} ------------ 49) 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.} ------------ 50) 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." ----------- 51) Bill: (26-jan-2012 email) 8.3.5.5 CFI_section: In Example 1 reference to CFI_establish, change "CFI_attribute_assumed" to "CFI_attribute_other". {Attribute renamed.} ------------ 52) Bill: (26-jan-2012 email) 8.3.5.5 CFI_section: In Example 2 reference to CFI_establish, change "CFI_attribute_assumed" to "CFI_attribute_other". {Attribute renamed.} ------------ 53) 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". ------------ 54) 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.} ------------ 55) Bill: (30-jan-2012 email) 8.3.5.8 CFI_select_part: In the description of the "source" formal parameter, change "assumed-shape" to "nonallocatable nonpointer". {The new CFI_attribute_other might be describing an array that is not assumed-shape.} ------------ 56) 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." ------------ 57) 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.} ------------ 58) 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".} ------------ 59) 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".} ------------ 60) 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." ------------ 61) 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.} ------------ 62) 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'. ------------ 63) 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.} ------------ 64) 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.} ------------ 65) 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" ------------ 66) Bill: (Editorial) 9.2 Edits to Introduction, in line 3 change "29113:2011" to "29133:2012". ------------ 67) 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.} ------------ 68) Bill: (Editorial) 9.9 edit beginning "{Before subclause 15.5}" In line 1 change "subclause " to "subclauses " twice, change "8.3" to "8.3 to 8.7", change "15.5" to "15.5 to 15.9", change "8.3.9" to "8.3.5" In line 2 change "15.5.9" to "15.5.5", change "15.6" to "15.10". {Changes required because of renumbering sections 8.3.6-8.3.9.} 9.9 last edit: Change "15.6.4" to "15.10.4". ------------ 69) 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} ------------ 70) 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.} ------------ 71) 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.} ------------ 72) 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".} ------------ 73) 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" ------------ 74) 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" ------------ 75) 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".} ------------ 76) 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: ============================================ 77) 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.} ------------ 78) 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." ------------ 79) 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.} ------------ 80) 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.} ------------ 81) 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.} ------------- 82) 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.} ------------ 83) 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.} ------------ 84) 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). ------------ 85) Van: (24-oct-2011 email, Ballot comment 6 of 26 from N1895) 8.3.4p6: It's not obvious what attribute cod 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.} ------------ 86) 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).} ------------ 87) 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 ------------ 88) 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.} ------------- 89) 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.} ------------ 90) 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.} ============================