ISO/IEC JTC1/SC22/WG5 N1848 Edits made to N1845 based on results of Ballot N1846. Bill Long, 31 May 2011 References (WG5 Documents): N1845 - TR 19113 Working Draft; basis for Ballot N1846. N1846 - Ballot for comments on N1845. N1847 - Results of Ballot N1846. N1848 - (This paper) N1849 - The updated TR 19113 Draft. This paper documents changes made to N1845 based on the responses to WG5 Ballot N1845 during March, 2011. Comments in formal Ballots and email postings to the interop-tr, j3-fortran, and WG5 email lists were considered. The paper is divided into three parts: 1) List of edits made in citation order, with editorial comments. Includes edits that were rejected by reason of being redundant with an edit proposed by someone else. 2) List of edits rejected other than those included in (1). 3) Collection of edits and issues which are still open for discussion. In addition to the edits listed in 1, there were multiple instances of font changes, mainly for correct usage of code font, and minor spacing and other typographical improvements. Identifiers for individual proposed edit citations, enclosed in {...} on the initial lines of edits: CER - Craig Rasumssen (USA, DOE) DM - David Muxworthy (UK, Edinburgh) JKR - John Reid (UK, WG5 Convenor) JX - Jim Xia (Canada, IBM) NM - Nick Maclaren (UK, Cambridge) MC - Malcolm Cohen (UK, NAG) RB - Reinhold Bader (Germany, LRZ) RG - Richard Graham (MPI Forum) VS - Van Snyder (USA, NASA) Ed - Bill Long (USA, Cray, TR Editor) Edits identified as {Ed} without "comment" represent edits added by the Editor for the reason indicated in the edit. All page and line number citations are to N1845. -------------------------------- Part 1: Edits made to N1845 to produce N1849. ====================================================================== -[Title page]------------------{DM Ballot comment} Remove reference to J3. -[iv:p5]-----------------------{Ed} Replace "2010" with "2011" in the formal identifier for the TR. {Old text was no longer accurate.} -[v:p4,L3-L5]------------------{RB Ballot comment, JKR comment} Replace "New Fortran concepts ... declared (void *)." by "New Fortran concepts of assumed-type and assumed-rank are introduced. The former facilitates interoperation with formal parameters of type (void *); both features together remove the necessity to write large numbers of specific calls in a generic Fortran interface to support arbitrary array ranks and types in a library call which implements generic functionality." {Ed: modified by (1) dehyphenate assumed-type and assumed-rank in first sentence. In second sentence change "facilitates" with "simplifies", since we already have a clumsy method. Replace "; both" with ". Both". Change "specific calls" to "specific interfaces". Finally, after email feedback on this change, replaced the sentence beginning "Both features..." with "The latter facilitates interoperability with C functions that can accept arguments of arbitrary rank."} -[v:p4,sentence 2]-------------{Ed} Remove hyphens in "assumed-type" and "assumed-rank". -[v, para 4]--------------------{RB email} Change "A" to "Annex A". {Ed: Assume ref is to para 7; made change there.} -[1:7]-------------------------{CER Ballot comment} Replace "excution" with "execution". -[1:8]-------------------------{VS Ballot comment 2} Insert a comma after "C" -[3:12]-------------------------{VS email} In clauses 2-5 the new syntax rules and constraints are numbered, e.g., R522x1, C535x1. In clause 6 they are numbered, e.g., R522a, C535a. This is a very fine point. Do we care? {Ed: [3:12] "C407x1" -> "C407a" [3:14] "C407x2" -> "C407b" [4:1] "R522x1" -> "R522a" [4:2] "C535x1" -> "C535a" [4:5] "C535x2" -> "C535b"} -[3:14]------------------------{NM, MC, JKR comments} After "variable" add "name". -[3:16+, TR17]-----------------{VS, RB Ballot comments} Convert [3:14-16] into Constraint C407x2. Remove UTI TR17. -[3:17+]-----------------------{NM, JKR, Ed email comments} Add a new Note after Note 2.1: "Note 2.2 This Technical Report provides no mechanism within Fortran code to determine the actual type of an assumed-type argument." {Ed: Corresponding edit in Clause 6 begins "This Standard...} -[4:3]-------------------------{Ed} After "variable" add "name". {Parallel edit to [3:14]} -[4:5+, TR18]------------------{VS Ballot comment 4} Convert [4:3-5] into Constraint C535x2. Remove UTI TR18. -[4:23]----------------------------{Ed, conclusion of email thread} Replace "This is deleted since it is no longer applicable." with "This is replaced by the much less restrictive constraint: C516 The ALLOCATABLE or POINTER attribute shall not be specified for a default-initialized dummy argument of a procedure that has a . NOTE 2.x It would be a severe burden to implementors to require that CFI_allocate initialize components of an object of a derived type with default initialization. The alternative of not requiring initialization would have been inconsistent with the effect of ALLOCATE in Fortran. {Ed: The problem addressed here is that CFI_allocate would have no practical means to perform default initialization of a Fortran derived type component. If you disallow ALLOCATABLE or POINTER for the dummy argument in the Fortran interface, then CFI_allocate will not see this case. Seems like relatively little is lost for the expected uses.} -[9:11 - end of document]-------{Ed, JKR email} Change the name of "CFI_establish_cdesc" to "CFI_establish" so it is more in line with the style of the other function names. Adjust spacing where needed. -[10:1-4]-----------------------{Ed} Delete the sentence "Its value is different from that of any other type identifier." in line 3. {This is redundant with [11:10-11].} Replace "identifier" with "specifier" 4 times. In the second and third instances, replace the preceding "an" with "a". {In [11:10-13] (and [10:5] ! ) these things are called "specifiers" as opposed to "identifiers" in [10:1-4]. Should be consistent.} -[10:12+]-----------------------{VS Ballot comment 10} 5.2.3p3-4 concern the ordering of dimensions (5.2.3p3), or the properties of the array as a whole (5.2.3p4), not the properties of one dimension. Those paragraphs should therefore be in 5.2.2. {Ed: Instead, moved 5.2.3 to come before 5.2.2, which collapses the space between these paragraphs and the end of the CFI_cdesc_t subclause.} -[10:18]------------------------{VS Ballot comment 12, Ed} Replace "of an array for a specified dimension" with "for the dimension being described". {Ed: The original edit added "lower Fortran bound", but that contradicts 5.2.3p2 at [10:22-23], so it was omitted from the final edit.} The edit for [10:12+] instead reordered the subclauses, so this dependency is not an issue. Edit not made.} -[10:19]--------------------------{VS Ballot comment 13} Replace "of an array along a specified dimension" by "along the dimension being described". -[10:21]---------------------------{VS Ballot comment 14} Replace "of the array along a specified dimension" by "along the dimension being described". -[10:23]--------------------------{Ed, JKR, VS email} Add a second sentence to paragraph: "For a descriptor of an allocatable or pointer array, the value of the lower_bound member of each element of the dim member of the descriptor is the Fortran lower bound." -[10:24-25]------------------------{VS comment 15} Replace "sm value" by "sm member" twice. {Ed: The original comment also included: Insert "the CFI_dim_t struct for" before "one dimension". The latter change is recommended because item 10 recommends to move this paragraph to 5.2.2. This change was not made because the text was rearranged differently.} -[10:28]-----------------------{Ed} Add a comma after "CFI_attribute_unknown_size". -[10:28-29]---------------------{VS Ballot comment 16, Ed.} Replace "member attribute" by "attribute member"; replace "member extent" by "extent member"; replace "member dim" by "the dim member". {Ed: Added "the" before "dim member" in the last edit.} -[10:31]------------------------{RB email} Change "CFI_DESC_T" to "CFI_CDESCT_T". -[11:Table 5.1]----------------{VS Ballot comment 17, Part 2} In Table 5.1 change "assumed-size" to "assumed size". -[11:11]------------------------{JKR Ballot comment} Change "an intrinsic" to "a". -[11:12]------------------------{JKR Ballot comment} Change "companion" to "Fortran". -[12:4]-------------------------{JKR email comment} Add "other than CFI_SUCCESS" after "each macro" -[12:3-6]-----------------------{JKR email comment} Change "this section" to "this subclause" three times. -[13:1]-[17:23]---------------{VS Ballot comment 18} Since C formal parameter names are written in lower case, it's not obvious from reading the text what is an argument name and what is an ordinary word. Either use "code font" for argument names, or the layout of the description of intrinsic functions that is used in Clause 13 of 1539-1 (or both). Constructions such as "argument dv" should be "dv argument" throughout 5.2.5. Otherwise one at first reads "argument result" or "argument attribute" or "argument type" to mean "the result of the argument" or "the attribute of the argument" or "the type of the argument". That is, "the argument type" reads too much like "the argument's type" at first glance. => Use \cf for formal parameter names. Reverse "argument xx" to "xx argument" Switch to a format with separate paragraphs for description and each format parameter, result value, and examples (if provided). {Ed: Reformatting guidelines. The Description sections are changed to be terse statements of the function's purpose. Separate paragraphs for each formal parameter. The functions CFI_address and CFI_is_contiguous have no side effects and are reformatted to resemble intrinsic functions in Clause 13. The other functions return an error value, but otherwise look like subroutine with side effects on (targets of) their arguments. These are reformatted more in the style of subroutines in Clause 13, with a description of the action in paragraphs following the argument list. Following those paragraphs, a Result Value section indicates that the return value is an error indicator. The detailed description of the error returns are in paragraph 3 of 5.2.5, and is not repeated for each function.} {Ed: As part of the reformatting, in the initial draft, the descriptions for each function that created a new descriptor included a paragraph of the form: "On successful execution of [function-name] the C descriptor pointed to by is updated. If an error is detected, that C descriptor is not modified." JKR email comment noted that the block of memory is not yet a descriptor at the beginning of the function execution. Recommended a change to: "On successful execution of [function-name] the object pointed to by is updated to the C descriptor established. If an error id detected, that object is not modified." Made this modification for CFI_establish, CFI_section, and CFI_select_part which are the functions that create new descriptors.} -[13:8+]---------------------{JKR email comment} Add new third paragraph to 5.2.5.1 General: "A C descriptor for a Fortran pointer can be constructed by execution of the functions described in this section. If a Fortran object without the TARGET attribute is associated with a formal parameter in a call to a C function and a C descriptor for a Fortran pointer to the formal parameter or a part of it exists on return, the base_addr member of the C descriptor becomes undefined on return." {Ed: Part of the proposed solution to UTI TR15. Changed "section" to "subclause" at end of the first sentence.} -[13:16-17]--------------------{VS Ballot comment 19} Provide a name, say "dv", for the CFI_cdesc_t formal parameter. After "C descriptor" insert "pointed to by the dv argument". -[13:21]----------------------------{Ed} Before the last sentence, add "The subscript values shall be within the bounds specified by the corresponding elements of the dim member of the C descriptor." {I assume we want to preserve the usual Fortran rule prohibiting out-of-bounds references.} -[13:19, 21]--------------------{VS Ballot comment 20} Replace "subscripts array" by "subscripts argument" twice. -[13:21+]-----------------------{JKR email} Add an example for CFI_address: " If {dv} points to a C descriptor for the Fortran array {a} declared as real a(100,100) the following code returns the address of {a(10,10)} CFI_index_t subscripts[2]; long int address; subscripts[0] = 10; subscripts[1] = 10; address = CFI_address( dv, subscripts );" -[13:22]------------------------{VS Ballot comment 21} Provide a name, say "dv", for the CFI_cdesc_t formal parameter. -[13:23]------------------------{JKR Ballot comment} At the end of the argument list add ", size_t elem_len". -[13:24]------------------------{VS Ballot comment 21a} Replace "an object" by "the object described by the C descriptor pointed to by the dv argument". -[13:26]-[14:1]-----------------{VS Ballot comment 21a, part 2} Replace "is not for" by "does not describe". -[14:1-8]-----------------------{Ed} Did not see where the current description says that the bounds arguments are ignored if the rank is zero. Added "If the rank is zero, the xxx argument is ignored" where xxx is "lower_bound" for the lower bound argument and "upper_bound" for the upper bound argument. {The updated format separated the argument descriptions.} -[14:2,3]-----------------------{VS Ballot comment 21b} Replace "arrays" by "arguments" twice. -[14:2-3]-----------------------{VS email comment, Ed} Is it really necessary for the number of elements of upper_bounds to be the same as the number of elements of upper_bounds, or is it sufficient that they both have at least r elements? {Ed: Reasonable point. Requirement of equal size removed in reformatted text.} -[14:3]-------------------------{VS Ballot comment 21c, Ed} After "rank" insert "$r$". Before "lower_bounds" insert "first $r$ elements of the". {Ed: Used \textit{r} instead to match usage in CFI_address.} -[14:4]-------------------------{VS Ballot comment 21d} Before "bounds" insert "Fortran" twice. -[14:7]-------------------------{JKR Ballot comment, Ed} Original edit: Before "The C descriptor" add "The argument elem_len is ignored unless type is a character type. Its value provides the length of an element of an object of character type." Reason: we should provide the functionality of the allocate statement for character objects. {Ed: This is separated as a new paragraph for the elem_len argument. In comparing to the elem_len argument for CFI_establish_cdesc, it appears that there is no mechanism for allocating a structure using CFI_allocate. Replaced the above edit with a copy of the description of elem_len from CFI_establish_cdesc.} -[14:8]-------------------------{VS Ballot comment 21e, Ed} Original edit: Replace "is" by "might be" since the "is" assertion was denied twice already. {Ed: Instead, incorporate the statement that the descriptor is updated into the sentence starting "on successful execution ..."} -[14:8+]------------------------{JKR email} Add an example for CFI_allocate: " If {dv} points to a C descriptor for the Fortran array {a} declared as real, allocatable :: a(:,:) and the array is not allocated, the following code allocates it to be of shape [100, 1000] CFI_index_t lower[2], upper[2]; int flag; size_t dummy; lower[0] = 1; lower[1] = 1; upper[0] = 100; upper[1] = 1000; flag = CFI_allocate( dv, lower, upper, dummy );" -[14:9]-------------------------{VS Ballot comment 22} Provide a name, say "dv", for the CFI_cdesc_t formal parameter. -[14:10]------------------------{VS Ballot comment 22a} Replace "an object that was" by "the object described by the C descriptor pointed to by the dv argument. It shall have been". -[14:16]------------------------{VS Ballot comment 22b, Ed} Original edit: Replace "is" by "might be" since the "is" assertion was denied twice already. {Ed} Instead, incorporate the statement that the descriptor is updated into a new sentence starting "on successful execution ..." -[14:16+]-----------------------{JKR email} Add an example for CFI_deallocate: " If {dv} points to a C descriptor for the Fortran array {a} declared as real, allocatable :: a(:,:) and the array is allocated, the following code deallocates it int flag; flag = CFI_deallocate( dv );" -[14:19]------------------------{VS Ballot comment 23} After "establishes" insert "the dv argument to be". -[14:28-29]---------------------{VS Ballot comment 23b} Before "a C descriptor" insert "the descriptor pointed to by the dv argument to be" twice. -[14:33-35]---------------------{JKR email comment} Delete the sentence "If the argument ...". {Ed: Part of the proposed solution for UTI TR15.} -[14:38]------------------------{VS Ballot comment 24, Ed} What are the units of the size of an element of the object? Bytes? Whatever is returned by the C sizeof operator? {Ed: The units are assumed to match the definition of the elem_len member of the struct at [9:31-33]. For a data type that is a struct, it is sizeof(struct). Replace "the size of an element" with "the sizeof() of an element" -[14:39]------------------------{VS Ballot comment 24b, Ed} What are the units of the length of an element of the character object? Bytes? Characters (which might be more than one byte each)? {Ed: The units are assumed to match the definition of the elem_len member of the struct at [9:31-33]. For a data type that is a struct, it is sizeof(struct). Replace "shall be the length of an element of the character type" with "shall be the number of characters in an element of the object times the sizeof() of a scalar of the character type" -[14:38-39]-------------------{JKR email comment} Change "a Fortran character" to "of Fortran character type". -[14:40]------------------------{RB email} Replace the numeric value "15" by "CFI_MAX_RANK". -[14:40-41]-------------------{Ed} After "argument rank" add "\textit{r}", and replace "rank elements" with "\textit{r} elements". {Avoid the specter of smelly elements.} -[14:41]----------------------{VS Ballot comment 25} Replace second "dim" by "Fortran dimension". -[14:42+]---------------------{CER Ballot comment} Page 14, following paragraph 7: There is no description of the dim argument. {Ed: The second sentence of paragraph 7 is the description of dim. In the new format the description of the dim argument is its own paragraph. Issue resolved by the format change.} -[15:6]------------------------------{Ed} Before "&field" insert "(CFI_cdesc_t *) " {Cast needed since CFI_CDESC_T(1) not identical to CFI_cdesc_t.} -[15:15]------------------------{Ed} Before "struct" add "typedef " -[15:19-21]---------------------{JKR Ballot comment, NM, CER} Change "->" to "." {Reason: dims[0] is not a pointer.} -[15:21]------------------------{Ed} Remove "struct" in argument of sizeof() -[15:22]-----------------------------{Ed} Before "&component" insert "(CFI_cdesc_t *) " {Cast needed since CFI_CDESC_T(1) not identical to CFI_cdesc_t.} -[15:23]------------------------{Ed} Remove "struct" in argument of offsetof(). -[15:27]------------------------{VS Ballot comment 26} Provide a name, say "dv", for the CFI_cdesc_t formal parameter. -[15:28]------------------------{VS Ballot comment 26a} Insert "descriptor pointed to by the dv" before "argument". -[15:30]----------------------------{Ed} After "attribute," add " CFI_rank_t rank," {We need a rank argument for CFI_section. Typically an array section has a different rank from its parent array, and there is currently no mechanism to specify that.} -[15:30]--------------------------{Ed} The functions CFI_section, CFI_select_part, and CFI_setpointer all have "result" and "source" arguments, plus other arguments that govern what is changed in result compared to source. It would be clearer and more consistent to arrange the arguments in the order result, source, for all three functions. CFI_setpointer is already that way. Edit: In the prototype for CFI_section, arrange the arguments in the order result, source, attribute, rank, dim. Reorder the argument description paragraphs in the same way, and modify example code throughout the remainder of the document. -[15:32]-------------------------{VS Ballot comment 27} Replace "result" by "the result argument". -[15:33]--------------------------{VS Ballot comment 27a} Replace "pointed to by source" by "described by the C descriptor pointed to by the source argument". -[15:38]--------------------------{VS Ballot comment 28} Replace "and" by "; it" or ". It". {Ed: Used ". It".} -[15:39+]---------------------------{Ed} Add a description of the rank argument to CFI_section: "rank specifies the rank of the object described by the C descriptor pointed to by result. It shall be between 1 and the rank of the object described by the C descriptor pointed to by source inclusive." -[15:42]--------------------------{VS Ballot comment 29} Replace "dim information of" by "Fortran dimension information for". -[15:42]---------------------------{Ed} Replace "rank elements" with "elements". After the replacement text from VS Ballot comment 29 edit, replace the rest of the sentence with "the array section described by the C descriptor pointed to by \cf{result}. The number of elements shall be the rank of the array section." {Make it clear that dim is used in the result descriptor.} -[15:42]---------------------------{JKR Ballot comment, Ed} At the end of the paragraph, add "The values of the elements shall be such that they specify an array that could have been obtained by associating source with a Fortran assumed-shape array and applying array section notation in Fortran." {Reason: In UTI TR16, Malcolm comments: "CFI section seems to allow nonsensical rank changing." I don't believe this is the case since we require the result C descriptor to describe a section of the array described by the source C descriptor. The edit aims to make this clear. } {Ed: In the second line of the edit text, replace "source" with "the source argument". (Suggested change by VS.)} -[16:4+]-----------------------{JKR email} Add "CFI_rank_t rank = 1" {Ed: Put at 4- instead, and added ";" at the end.} -[16:6-8]-----------------------{JKR Ballot comment, NM, CER} Change "->" to "." {Reason: dims[0] is not a pointer.} -[16:9]------------------------------{Ed} Before "§ion" insert "(CFI_cdesc_t *) " {Cast needed since CFI_CDESC_T(1) not identical to CFI_cdesc_t.} -[16:8-9]-----------------------{CER Ballot comment, Ed} Page 16, lines 8-9: The type of the source variable is not stated, in particular, whether it is a pointer. The usage in line 8 implies it is a pointer, the usage in line 9 that it is not a pointer. {Ed: The text at [16:1] says that source is a pointer. Edit: Remove the "&" before "source" in [16:9].} -[16:9]------------------------{JKR email} Add "rank," before "source". {Ed: rank is a new argument here - add before the edit above.} {Ed: RB proposed adding "1" instead for this same change. I chose the JKR edit as more illustrative, and explicitly having the right type.} -[16:11]--------------------------{Ed} The functions CFI_section, CFI_select_part, and CFI_setpointer all have "result" and "source" arguments, plus other arguments that govern what is changed in result compared to source. It would be clearer and more consistent to arrange the arguments in the order result, source, for all three functions. CFI_setpointer is already that way. Edit: In the prototype for CFI_select_part, arrange the arguments in the order result, source, attribute, type, displacement, elem_len. Reorder the argument description paragraphs in the same way, and modify example code throughout the remainder of the document. -[16:13]-----------------------------{VS Ballot comment 30} Replace "a C descriptor" by "the C descriptor pointed to by the result argument" {compare 5.2.5.7p1}. -[16:13-14]--------------------------{VS Ballot comment 31} This only works for one part at a time. Replace "whose elements are parts" by "for which each element is a part". Replace "The parts" by "The part". -[16:20]-----------------------------{VS Ballot comment 32} Replace "and" by "; it" or ". It". {Ed: Used ". It".} -[16:23]-----------------------------{VS Ballot comment 33, Ed} Replace "arguments displacement and elem_len" by "displacement and elem_len arguments". {Ed: Subsumed when the descriptions for arguments type and displacement were made into separate paragraphs.} -[16:23-24]------------------------{RB email} Are empty subobjects allowed? otherwise perhaps "elem_len" should be replaced by "elem_len -1". {Ed: This edit refers to the form of the argument descriptions after they are separated into separate paragraphs for each argument. This edit applies to the displacement argument. C does not have the concept of an empty struct. And none of the other interoperable types have zero size, so elem_len should not be zero. The proposed edit ends up reading "the elem_len-1 member..." which does not fit. Simpler to replace "the elem_len member of the C descriptor pointed to by source" with "source->elem_len-1".} -[16:23-24]------------------------{RB email} Replace "0" by "1" (in para 6 it says elem_len is "greater than zero"). {Ed: Parallel to the edit above I also replaced "the elem_len member of the C descriptor pointed to by source" with "source->elem_len". The new text is simpler, and also correct, since the value is actually between 0 and the *value of* the elem_len member...} -[16:24]------------------------{JKR email} After "source" add "inclusive". {Ed: Added "inclusive" at the end of the sentences modified by the previous 2 edits.} -[16:28]------------------------------{VS Ballot comment 34, Ed} Replace "type" by "the type argument". {Ed: This edit is subsumed by the following edit.} -[16:28-30]--------------------------{Ed} Replace the text for the description of the elem_len argument with the revised text specified for [14:37-39], resulting from VS Ballot comments 24 and 24b. -[16:40]------------------------{CER Ballot comment} Remove comma in "component,;" -[16:43]-----------------------------{Ed} Before "&component" insert "(CFI_cdesc_t *) " {Cast needed since CFI_CDESC_T(1) not identical to CFI_cdesc_t.} -[16:44]------------------------{CER Ballot comment, Ed} At [16:39] replace "double d;" with "struct { double x; double complex y;} t;" In [16:44] Replace "sizeof(d)" with "offsetof(struct t, y)" {The use of sizeof(d) for the displacement argument assumes a particular layout of the interoperable type t, which is processor dependent.} -[17:7]-----------------------{VS Ballot comment 35} Before \cf{ptr_dv} insert "the Fortran pointer described by the C descriptor pointed to by" -[17:7]-----------------------{JKR Ballot comment, Ed} Change " becomes a disassociated pointer" to "the C descriptor is updated to describe a disassociated pointer". Reason: Correct a minor error. {Ed: Integrated with previous edit for same sentence.} -[17:6-7]---------------------{JKR subsequent email} Change "Fortran pointer ... describe" to "updated C descriptor describes". -[17:9]-----------------------{VS Ballot comment 35a} Replace "\cf{ptr_dv} C descriptor" by "C descriptor pointed to by \cf{ptr_dv}". -[17:9-10]---------------------{JKR email comment} Delete the sentence "If the source is not NULL.." and delete UTR TR15. {Ed: See related edit at [13:8+] for the replacement.} -[17:11]-----------------------{VS Ballot comment 35b, Ed} C doesn't use the term "target of". Replace "target of \cf{ptr_dv}" by "the C descriptor pointed to by \cf{ptr_dv}". {Ed: The original edit citation was [17:1] which contradicted 5.2.5.9p5. I assume the correct citation is [17:11].} -[17:11-14]----------------------{Ed} Revise the description of the dim argument to be parallel to that of the dim argument of CFI_section. Include the edits from the [15:42] JKR edit, as they would apply similarly here. -[17:1-14]-----------------------{Ed} Throughout the description of CFI_setpointer, replace "ptr_dv" with "result" for consistency with CFI_section and CFI_select_part. Move UTI TR15 to [17:14+] to avoid it being embedded in the argument description construct. -[17:1]--------------------------{JKR email comment} {Ed: This is a set of changes to address UTI TR16} Change "CFI_dim_t dim[]" to "CFI_index_t lower_bounds[]". at [17:4]. Change "dim" to "lower_bounds". at [17:12-14] Replace the two sentences "Otherwise, ... ptr_dv" by "Otherwise, the number of elements in the array lower_bounds shall be greater than or equal to the rank specified in the source C descriptor. The elements provide the lower bounds for each corresponding dimension of the ptr_dv C descriptor. The extents and memory strides are copied from the source C descriptor." {Ed: Modified to change "ptr_dv" to "result".} at [17:17-23] Replace these lines by "to this with lower bound 0. CFI_index_t lower_bounds[1]; int ind; lower_bounds[1] = 0; ind = CFI_setpointer ( &ptr, &ptr, lower_bounds );" {Ed: Corrected line 3 of the code to "lower_bounds[0]"} at [17:23+] Remove UTI TR16. -[17:20-22]---------------------{JKR Ballot comment, NM, CER} Change "->" to "." {Reason: dims[0] is not a pointer.} {Ed: Overridden by the previous edit.} -[17:23]------------------------{CER Ballot comment, Ed} It is stated that ptr point to a C descriptor yet the address operator & is used with ptr in the call to CFI_setpointer. {Ed: Original citation was to [18:23], but the text matched [17:23], which I assume is the correct citation. Edit: in [17:23} remove both "&".} {Ed: Applied this correction to the replacement example.} -[18:9]---------------------{VS email} Allocation status is never undefined. {Ed: delete "allocation or" in line 9.} -[19:1-2]---------------------{RB email} There are some more leftovers from when TYPE(*) still allowed ALLOCATABLE/POINTER (probably not purely editorial, but so far overlooked). {Ed: Since we have a constraint that allocatable and pointer are not allowed for TYPE(*), the "not allocatable" and "a pointer" are not relevant here. Edit: Change "not allocatable, assumed-shape, assumed-rank, or a pointer" to "not assumed-shape or assumed-rank".} -[21:1+]-----------------------{Ed} Add "6.1 General", as the current form does not conform to the ISO structure guidelines. -[21:7-8]----------------------{DM Ballot comment} Remove paragraph 3 as it is relevant only to the J3 document. Remove the associated references throughout Clause 6. -[21:12,14]--------------------{DM Ballot comment} Change "TS 29113" to "TR 29113" twice. -[22:8]-------------------------{JX, IBM C group email} Before "assumed type" add "of". -[22:14]-----------------------{NM, MC, JKR comments} After "variable" add "name". {Same edit as for [3:14].} -[22:14-16]-------------------------{Ed} Make the same change as indicated for [3:16+, TR17] here. -[22:17+]---------------------------{JKR email, Ed} Corresponding to the edit at [4:23], add new lines to 6.4: {In 5.3.1 Constraints, replace C516 with} C516 The ALLOCATABLE or POINTER attribute shall not be specified for a default-initialized dummy argument of a procedure that has a . -[23:7]------------------------{Ed} After "variable" add "name". {Parallel edit to [22:14]} -[23:7-9]--------------------------{Ed} Make the same change as indicated for [4:5+, TR18] here. -[23:10-----------------------{JKR Ballot comment} Change "an array or scalar" to "a data" and delete UTI TR19. Reason: The UTI can be resolved by changing the sentence to which it refers to be that in 2.2. -[29:10]----------------------{RB Ballot comment} Delete "or explicit shape". {Explicit shape is no longer allowed by [3:11] constraint C407x1 in 2.1.} -[29:12-13]-------------------{RB Ballot comment} Replace "All unlimited polymorphic ... shape or rank," by "All assumed-type entities of assumed shape or rank". {Ed: Assumed-type dummies are not allowed to have the ALLOCATABLE or POINTER attributes, so the old sentence was defective anyway.} -[31:16]----------------------{RB Ballot comment} "would be rejected during compilation" requires that 2.1 para 3 is made a constraint. {Ed: Removed the cited sentence fragment.} -[31:25,29]---------------------{JKR email} In line 29, remove "*" then move it to replace line 25. [Not wrong at present, but more elegant after the change.] -[31:31]----------------------{RB Ballot comment} Prepend second "status =" with "*". -[31:41+ TR20]----------------{Reinhold Ballot comment} -[31:33]-[33:14]--------------{JKR Ballot comment} Delete A.1.3 and UTI TR20. Reason: This example is not valid in view of the constraint in 2.1. {Added comment by RB on same section: Apart of the removal or modification of A.1.3 it will also be necessary to make changes to [29:12-13].} {Ed: [29:12-13] were replaced by a different edit previously.} -[31:33]-[33:13]--------------{RB Ballot comment} [A.1.3]: It is suggested to replace this example by a valid one which illustrates the array subobject handling capabilities and type resolution for an unlimited polymorphic actual argument. I'll write this up as a separate paper, which will be submitted for the June meeting. -[36:11+]---------------------{RB Ballot comment} Insert a new line: "/* other necessary includes omitted */" -[36:19]----------------------{RB Ballot comment} Move "{" to end of previous line; delete resulting blank line. {Change to bracketing convention used in other examples.} -[36:34]----------------------{RB Ballot comment} Move "{" to end of previous line; delete resulting blank line. {Change to bracketing convention used in other examples.} -[37:5]-----------------------{RB Ballot comment} Move "{" to end of previous line; delete resulting blank line. {Change to bracketing convention used in other examples.} -[37:14]----------------------{RB Ballot comment} Move "{" to end of previous line; delete resulting blank line. {Change to bracketing convention used in other examples.} -[37:14]------------------------{RB email} Replace "int" by "void" (function does not produce a return value) -[37:17]------------------------{RB email} Replace "CFI_is_Contiguous" by "CFI_is_contiguous" -[37:34]----------------------{RB Ballot comment} Replace "desirable" by "necessary". -[37:39-41]-------------------{RB Ballot comment} Replace "CFI_DESC_T" by "CFI_CDESC_T" and (3 times) "CFI_cdest_t" by "CFI_cdesc_t". -[37:43]----------------------{RB Ballot comment} Rewrite line as "CFI_rank_t rank = 2; int flag;" -[37:51]---------------------{RB Ballot comment} Remove "[]" in "dims[]" -[38:10]---------------------{RB Ballot comment} Remove "[]" in "dims[]" -[38:10]----------------------{JKR email comment} Change "dims" to "desc_alloc->dim". {Reason: The array was allocated during the Fortran call.} {Ed: Also, the words at [37:36] and [38:3] say that we are using the dim array from desc_alloc, so we should actually do that.} -[38:15-24]---------------------{JKR email} (which anyway should be all one para.). Replace by "Given the Fortran subprogram subroutine set_all(int_array, val) bind(c) integer(c_int) :: int_array(:) integer(c_int), value :: val int_array = val end subroutine that sets all the elements of an array and the Fortran interface interface subroutine set_odd(int_array, val) bind(c) use, intrinsic :: iso_c_binding, only : c_int integer(c_int) :: int_array(:) integer(c_int), value :: val end subroutine end interface for a C function that sets every second array element, beginning with the first one, the implementation in C reads" -[38:32-34]--------------------{JKR Ballot comment, NM, RB} Change "->" to "." {Reason: dims[0] is not a pointer.} -[38:36]----------------------{RB Ballot comment} Before "&array", insert "(CFI_cdesc_t *)" -[38:44]----------------------{RB Ballot comment} Before "array", insert "(CFI_cdesc_t *) &" -[39:5-10]----------------------{JKR email} Delete para 5. {Ed: integral part of [38:15-24] edit above.} -[39:27+]----------------------{RB Ballot comment} Add a line "CFI_index_t subscripts[1];" -[39:32-34]---------------------{JKR Ballot comment, NM, RB} Change "->" to "." {Reason: dims[0] is not a pointer.} -[39:36]----------------------{RB Ballot comment} Before "&d", insert "(CFI_cdesc_t *)" -[39:41]----------------------{RB Ballot comment} Remove last blank in "rank * /" -[39:44]----------------------{RB Ballot comment} Before "d,", insert "(CFI_cdesc_t *) &" -[40:2]-----------------------{RB Ballot comment} Before "d, subscripts", insert "(CFI_cdesc_t *) &" ================================================================ Part 2: Suggested edits that were not made. =========================================== -[v:p5,L2]--------------------{VS Ballot comment 1} Replace "require that any changes be made" by "require any changes to be made". {Ed: Not clear this is an improvement.} -[3:17+]----------------------{JKR Ballot comment} Extended discussion about Note 2.1. (See N1847 for full text.) {Ed: Following an email discussion, the alternative edit in Part 1 was used instead.} -[4:23+]----------------------{CER and RG Ballot comments} Both CER and RG, from the MPI Fortran committee, requested modifications to the semantics of the ASYNCHRONOUS attribute in the base Fortran standard so that it would be useful for the "buffer" arguments to non-blocking MPI routines. (See N1847 for full text.) {Ed: After a extensive email discussion on both the interop-tr and mpi email lists, the MPI group decided to withdraw this request.} -[5:15-16]---------------------{VS Ballot comment 5} Should be a constraint. But... similar provisions in Clause 12 of 1539-1 are not constraints. {Ed: As noted, there are other similar restrictions in Clause 12 of the base standard that are not constraints. Choose to follow that pattern here. This can be revisited during integration if desired.} -[5:15-16]----------------------{JKR Ballot comment} Replace para 2 of 3.3 to "An assumed-type dummy argument may correspond to an actual argument that is of assumed type or any type except a derived type that has type parameters, type-bound procedures, or final procedures. If the actual argument is of assumed type and the dummy argument is not of assumed type, the actual argument shall be an object of assumed shape or assumed rank or a subobject of such an object and the type shall be one of those explicitly listed in Table 5.2." (Added discussion in N1847.) {Ed: The first sentence says the same thing as the current [5:15-16] text. The second sentence discusses a situation that is disallowed by the text at [3:14-15] "An assumed-type variable shall not appear ... except as an actual argument corresponding to a dummy argument that is assumed-type...".} -[7:3]-------------------------{VS Ballot comment 6} Insert "subclause" before "4.2". {Ed: Inconsistent with ISO style.} -[9:3-5]------------------------{RB Ballot comment} Replace "with standard prototypes provide" by "specified in 5.2.5 provides". Replace "for describing an" by "for creating, referencing and defining a Fortran". (this indicates more clearly that not only dummy arguments are handled, but also Fortran object management within C is supported). After "data pointer object" add "of interoperable type" (for non-interoperable types it is allowed to pass a handle through C - do we want to mention this explicitly?) {Ed: I would not want to replace "with standard prototypes". We could insert a "specified in 5.2.5", but that is not critical. A C programmer could certainly use the facilities to have a set of assumed-shape objects wholly within C. It is not clear that we should require that these be called "Fortran" objects.} -[9:9]--------------------------{VS Ballot comment 7} It is not clear what base types CFI_attribute_t, CFI_index_t, CFI_rank_t and CFI_type_t have. They are simply described as "typedef". "typedef" for what? Integers, I suspect. The base type should be specified. {Ed: Edit not needed. The descriptions are at: CFI_attribute_t : [10:8-9] CFI_index_t: [10:15-16] CFI_rank_t: [9:37-38] CFI_type_t: [10:4-5] } -[9:17]-------------------------{RB Ballot comment} Replace "no effect different from" by "an effect no different from" {Ed: Nick went to great pains to craft these words paralleling the C usage. I prefer to not change them.} -[9:19-21]-----------------------{VS Ballot comment 8} Is there a good reason to prohibit a C source file from having any identifiers other than the ones gotten from ISO_Fortran_binding.h to begin with CFI_? A "google" search for "CFI" returned 6,320,000 results, so it is conceivable that a pre-existing C file might have identifiers beginning with CFI, and then someday need to be interoperable. For example, at http://www.gocfi.com we see "CFI provides Enterprise Asset Management, Computerized Maintenance Management System, Archibus, CMMS Software,...." If possible, delete this paragraph. {Email answer from NM: The reason is that not doing that means that any future will break at least some valid C code. Worse, at least some valid C code will change meaning, but not get a diagnostic. It's a pain, I agree, but such restrictions are normal practice in C interfaces, for that very reason. People have learnt from the experience of not doing it!} {Ed: Accept answer for leaving text as is.} -[9:22+]------------------------{CER Ballot comment} CFI_cdest_t contains a flexible array member and there is a macro CFI_CDESC_T for declaring a C descriptor with a given rank, however there doesn't appear to be a function to obtain the sizeof a CFI_cdest_t with a given rank. A mechanism to obtain the size of a C descriptor is necessary if one needs to create a long-lived descriptor in C using malloc. {Ed: No actual edit was proposed here. Can't you compute the size of a descriptor of a particular rank by creating one and employing sizeof?} -[9:23]-------------------------{VS Ballot comment 9} CFI_cdesc_t is described as a "typedef" but it's not in the list of "typedef" names in 5.2.1p1. Is there a more precise C term that could be used here? I didn't know that a "typedef" had members. Is "typedef for a struct" correct? {Ed: CFI_cdesc_t is not described as a typedef. It is a "named struct" that is "defined by a typedef". It is listed in 5.2.1p1 as a struct, which is correct. Edit not needed.} -[9:34-35]-----------------------{RB Ballot comment} Delete the version component from CFI_cdesc_t. Logic: After recent discussions about dead weight in the descriptor - does this not also apply to the version component of CFI_cdesc_t? (Given the first sentence of NOTE 5.3 I don't think adding this feature is worth the trouble. Witness the need to completely recompile Fortran code whenever the module information format is incompatibly changed). {Ed: The utility of the version member has been extensively debated and voted. It has valuable uses within the library functions to prevent mis-interpretation of an incompatible descriptor.} -[10:14]-------------------------{VS Ballot comment 11} CFI_dim_t is described as a "typedef" but it's not in the list of "typedef" names in 5.2.1p1. Is there a more precise C term that could be used here? I didn't know that a "typedef" had members. Is "typedef for a struct" correct? {Ed: CFI_dim_t is not described as a typedef. It is a "named struct" that is "defined by a typedef". It is listed in 5.2.1p1 as a struct, which is correct. Edit not needed.} -[11:4+,Note 5.3]---------------{RB Ballot comment} From NOTE 5.3, replace ", and that the version ... Technical Report." by ". Such a change indicates that all C source code using the facilities provided by ISO_Fortran_binding.h must be recompiled." {Ed: The current text is intended to allow for a processor to accommodate a descriptor created using an obsolete header file, possibly by providing translation between known versions. The proposed edit removes that case.} -[11:5+, Table 5.1]-------------{VS Ballot comment 17, part 1} In Table 5.1 Replace "assumed" by "assumed shape" (to distinguish from "assumed type" or "assumed rank"). {Ed: Assumed-type and assumed-rank are not relevant concepts in C.} -[11:13+]-----------------------{RB Ballot comment} Should there not be the requirement in normative text that the macro values for C types interoperating with the same Fortran type must be the same? Edit: Add "The specifiers for two intrinsic C types must have the same value if they interoperate with the same Fortran type." {Ed: Seems like an unnecessary requirement. For example, a Fortran processor might represent a default integer by the CFI_type_int value, and represent and integer(4) by the CFI_type_int32_t value and, for some reason, wish to make a distinction.} (It might even be desirable to fix these to be the same value as the corresponding Fortran KIND number so you can pass them through to Fortran) {Ed: This would not work. The KIND value of 4 applies to both INTEGER and REAL types.} -[12:1-]------------------------{RB Ballot comment} Remove NOTE 5.4 {Ed: Depends on [11:13+] edit above.} -[13:6-8]-----------------------{RB Ballot comment} Fortran pointers can also be associated via CFI_setpointer(); the paragraph also needs rewording so it is clear that "Within C" applies to all of it. Edit: After "Within a C function, " start a bullet list with "* allocatable objects ... functions. * a Fortran pointer ... function", and add ", or by execution of the CFI_setpointer function" to this second bullet. {Ed: The topic of the paragraph is the CFI_allocate/deallocate functions. Maybe some wordsmithing about the "Within C" bit, though "executing CFI_allocate" should make that unambiguous.} -[13:13]----------------------{RB Ballot comment} Replace "which error condition ... dependent" by "it is processor dependent which error condition is detected" {Ed: The existing sentence style is similar to other places in the standard. For example, [76:5-6].} -[13:17-21]-------------------{RB email} The bounds are not specified by dim. Perhaps "shall be within the bounds inferred by the corresponding ...", or even "shall be within the bounds of the Fortran object which is described by the C descriptor." {Ed: Note that this edit was proposed to a later edition of the draft. The sentence in that draft, in the description of the 'subscripts' argument is "The subscript values shall be within the bounds specified by the corresponding member of the C descriptor." The bounds are trivially computed from the lower bound and extent members of dim. This sufficient to say they are "specified" by those members. (As opposed to being "equal".) The current wording is consistent with the use of "specified". JKR comment: I agree with you that no change is needed.} -[14:19]----------------------{RB Ballot comment} After "an assumed-shape array, ", add "an array section, ". {Ed: An array section is an array.} -[14:27]----------------------{RB Ballot comment} after "1999 3.2)", add " and of sufficient size". After " type", add ", rank and dimensions". {Ed: The text being modified refers to the base address, requiring that it be properly aligned for the type. The size of the base address is already specified in the prototype (void *), which is inherently sufficient, and the alignment would not depend on the rank and dimensions of the object.} -[15:34]-------------------------{JKR email} Change "described by ... result" to "to be established". {Ed: This edit was aimed at a later draft that contained text of the form "xxx specifies the xxx of the object described by the C descriptor pointed to by result". The modified text results in "xxx specifies the xxx of the object to be established". But, the object is not being established. Its C descriptor is. JKR sent 4 such edits, all with the same context.} -[15:30]-[16:10]--------------{RB Ballot comment} It appears to me that CFI_section does not provide any functionality which is not covered by CFI_establish_cdesc. The only example in the TR is [16:3-9], and that can also be changed to use CFI_establish_cdesc instead. Why not remove this function? (the same argument could be applied to CFI_select_part, however the latter function does make subobject selection code easier to read, so I'd be OK with retaining it). Edit: Delete CFI_section. (If this is retained, [15:35-36] may require modification in analogy to [14:22-24].) {Ed: CFI_section provides a simpler interface than CFI_establish_cdesc since it allows reuse of the information in source. It seems reasonable to have a separate function for this, given that it is a relatively common operation. It is also the case that the source argument may be providing vendor-specific fields that would have different values than the defaults used by CFI_establish_cdesc.} -[17:12]------------------------{JKR email} Delete sentence "The ... section." [Not helpful - the rank is that of source.] {Ed: The sentence referred to is in a later draft. It is in the paragraph describing the dim argument to CFI_setpointer, and reads "The number of elements shall be the rank of the array section." The number of elements of the dim member of the input C descriptor has to be its rank. But this dim is not part of either descriptor. It is an argument to the function. The statement is that this argument shall have the correct number of elements.} -[29:6]-----------------------{RB Ballot comment} Replace "entities whose dynamic type is interoperable with C" by "dummy arguments in a BIND(C) interface" {Ed: This change looses the connection between "entity" in the current text and the "An entity" at the beginning of the two items that follow.} -[29:8]-----------------------{RB Ballot comment} Replace "This is a start address" by "This could be a start address". {Ed: What else would it be?} ==================================================== Part 3: Unresolved issues ============================== -[13:8+]------------------------{JKR Ballot comment} Add new third paragraph to 5.2.5.1 General: "A C descriptor for a Fortran pointer can be constructed by execution of the functions described in this section. If a Fortran object without the TARGET attribute is associated with a formal parameter in a call to a C function and a C descriptor for a Fortran pointer to the formal parameter or a part of it exists on return, the base_addr member of the C descriptor becomes undefined on return." {Ed: But the C descriptor will always become undefined on return to Fortran.} Related edits from John: [14:33-35] Delete the sentence "If the argument ...". [17:9-10] Delete the sentence "If source is not NULL ..." and DTI TR15. Reason: See DTI TR15. An object without the TARGET attribute may be associated with a dummy argument that has the TARGET attribute. This is fine until return from the procedure, when any pointers associated with the dummy argument become undefined. We need the same rule for Fortran calls to C. CFI_establish_cdesc and CFI_setpointer have the wrong restriction and the rule needs to be more general. Related comment from RB: [14:34-35]: This may also be impacted by UTI TR15. -[14:22-24]-------------------{RB Ballot comment} For a C formal parameter of type (CFI_cdesc_t *), a corresponding Fortran dummy argument need not exist, but the requirement should be fulfilled anyway. Furthermore, the requirement itself is replicated three times for as many intrinsics, so it is suggested to move this to section 5.2.6 (see also [17:26] below) Edit: Delete "It shall not point ... Fortran dummy argument". Also proposed as edit for [16:17-19]. {Ed: The deleted statement is needed somewhere.} -[14:41-42]-------------------{RB Ballot comment} Replace "specifying the dim information" by "which will be written to the dim[] member of dv" {Ed: The "which will be written" could contradict the claim that the target of dv is not modified if there is an error. We need to say somewhere that the values of the various arguments get written to the target of dv if there is no error. That seems to be covered by the "the properties of the object are given by the other arguments". Do we need to be more specific, perhaps in the "is updated" sentence?} -[14:43+]---------------------{RB Ballot comment} Add "NOTE 5.5+: If the base_addr is that of a Fortran array accessed via a C descriptor /d/, dim[] can be constructed from /d->dim[]/ such that dv describes an array subobject of /d/. It is the responsibility of the programmer to ensure that the settings of dim[] as well as the other arguments provide a consistent view of the layout of the original Fortran object." (with respect to UTI TR 16 note that CFI_establish_cdesc effectively also allows nonsensical rank changing. But we can't really change this since we also want to be able to plug in addresses of C objects here). {Ed: Should coordinate the words with those used for CFI_setpointer and CFI_section.} -[17:1]------------------------{RB Ballot comment} John Reid has suggested replacing the CFI_dim_t parameter by a lower bounds argument. However, this change makes the example in para 7 unworkable. Why not have a full subscript triplet array CFI_dim_t subscripts[3][] as a replacement for dim[]? {Ed: The example is a problem, but it could be moved to the CFI_section subclause. The CFI_section function is a more logical choice for this anyway.} -[17:1]-----------------------{JKR Ballot comment} Change "CFI_dim_t dim[]" to "CFI_index_t lower_bounds[]". -[17:12-14]-------------------{JKR Ballot comment} Replace the two sentences "Otherwise, ... ptr_dv" by "Otherwise, the number of elements in the array lower_bounds shall be greater than or equal to the rank specified in the source C descriptor. The elements provide the lower bounds for each corresponding dimension of the ptr_dv C descriptor. The extents and memory strides are copied from the source C descriptor." Reason: We should be providing the functionality of pointer association with the option of specifying the lower bounds and nothing more. -[17:23+]---------------------{JKR Ballot comment} Delete UTI TR16. Reason: See the edits for [15:42], [17:1], [17:12-14]. The UTI also says "It would be helpful to create a list of all of the possible forms of pointer association and argument association involving dope vectors, and illustrate how each is accomplished with corresponding calls to these functions. It is possible the exercise would lead to a slightly changed set of functions." All that I see as missing is 1. The equivalent of pointer assignment with remapping. I don't think we should complicate CFI_setpointer with remapping - the C programmer can do this with CFI_establish_cdesc. 2. Array sections with vector subscripts. It has never been envisaged that vendors would construct descriptors for such array sections and that copies would be made when they are used as actual arguments - the C programmer can make copies explicitly. -[17:26]-[18:1]---------------{RB Ballot comment} N1830 has two constraints (C539/C540) here which may require some modification since within a C implementation checking violations at compile time will probably not be possible (there may also be an issue in F2008 for the case where an interface is specified separately from the implementation). Furthermore, the TR should also differentiate between modifying data (for non-pointers with INTENT(IN)) and metadata (for pointers). Proposed edit: Replace "A C descriptor that is ... not be updated" by "The following rules apply for a C descriptor /d/ that describes an object that is described by a C descriptor pointed to by a formal parameter /dvarg/ of type (CFI_cdesc_t *): * /d/ must not appear as the dv argument in a call to CFI_establish_cdesc[, the result argument in a call to CFI_section], or the result argument in a call to CFI_select_part. * if a Fortran dummy argument corresponding to /dvarg/ exists and has the INTENT(IN) attribute, /d/ must not appear as the XXX argument in a call to CFI_allocate or CFI_deallocate. * if a Fortran dummy argument corresponding to /dvarg/ exists and has the INTENT(IN) and POINTER attributes, /d/ must not appear as the ptr_dv argument in a call to CFI_setpointer. * if a Fortran dummy argument corresponding to /dvarg/ exists and is a non-pointer entity with the INTENT(IN) attribute, no modification of data accessible via /d->base_addr/ is permitted." Add "NOTE 5.5+: For Fortran pointer entities with the INTENT(IN) attribute it is recommended that the C programmer add a 'const' specifier to the corresponding parameter of type 'CFI_cdesc_t *' in the C prototype." -[18:5-7]---------------------{RB Ballot comment} This appears at least partly superfluous, at least it is not very clearly worded. There's a suggestion for changes to [9:3-5] below which would allow to remove this. Edit: Delete these lines. -[18:28-29]-------------------{VS Ballot comment 36} Why did we go to the trouble to develop descriptors for array arguments, and then not allow (a pointer to) one as a function result? This should allow the result to have the Fortran POINTER or ALLOCATABLE attribute. The result would be a C pointer to a descriptor of type CFI_desc_t. The processor should be able to handle this with the same mechanisms it uses for arguments. {Ed: I'm reluctant to entertain feature creep at this point. This could be reconsidered during integration into the base standard.} -[38:49]-[39:4]----------------{RB Ballot comment} The wording still reflects the assumptions in N1838 and requires some changes. Replace the text by "A copy of the incoming descriptor must be created because of the provisions in section 5.2.6." <> "The example demonstrates why these rules are reasonable: If the original descriptor were updated with the dim[] settings above, it would be irreversibly modified, preventing access to some of its original data in the implementation's code after invocation of CFI_establish_cdesc or - after the call site - for a C function which invokes set_odd (see below). -[31:33 - 33:13]--------------{RB Ballot comment} {Ed: This is a proposed replacement for A.1.3} {Ed: In a subsequent email, RB made this change: Please replace the second occurrence of extract_vec "call extract_vec(one_d_field, 1, v1, 1)" by "call extract_vec(one_d_field, 2, v1, 1)" The following text incorporates that change.} "Assuming that a Fortran object declared CLASS(*), ALLOCATABLE, TARGET :: one_d_field(:) will be allocated (within Fortran) to be an array of one of the following interoperable types: (1) a REAL(kind=c_float) (2) of type type, bind(c) :: scalar_vector REAL(kind=c_float) :: scalar REAL(kind=c_float) :: vec(3) end type (3) of type type, bind(c) :: scalar_vector_matrix REAL(kind=c_float) :: scalar REAL(kind=c_float) :: vec(3) REAL(kind=c_float) :: mat(3,3) end type and it is desired to access an element of the object's vector part using the Fortran interface subroutine extract_vec(field, tag, vector_comp, ic) bind(c) use, intrinsic :: iso_c_binding type(*), target :: field(:) real(kind=c_float), pointer :: vector_comp(:) integer(kind=c_int), value :: tag, ic end subroutine The /tag/ argument informs the subprogram about the dynamic type of /field/. A C implementation for the subprogram then is #include "ISO_Fortran_binding.h" typedef struct { float scalar; float vec[3]; } scalar_vector; typedef struct { float scalar; float vec[3]; float mat[3][3]; } scalar_vector_matrix; void extract_vec(CFI_cdesc_t *field, int tag, CFI_cdesc_t *vector_comp, int ic) { int vstat; CFI_CDESC_T(1) fsub; if (field->rank != 1) { : // throw error } if (field->type == CFI_type_float) { // scalar case - produce NULL() vstat = CFI_setpointer(vector_comp, NULL, NULL); } else { switch (tag) { case 1: // type is scalar_vector CFI_select_part( (CFI_cdesc_t *) &fsub, CFI_attribute_assumed, field, CFI_type_float, offsetof(scalar_vector, vec[ic]), 0 ); break; case 2: // type is scalar_vector_matrix CFI_select_part( (CFI_cdesc_t *) &fsub, CFI_attribute_assumed, field, CFI_type_float, offsetof(scalar_vector_matrix, vec[ic]), 0 ); break; } vstat = CFI_setpointer(vector_comp, (CFI_cdesc_t *) &fsub, NULL); } if (vstat != CFI_SUCCESS) { : // throw error } } /vector_comp/, being an entity with the POINTER attribute, will be validly aliased to the appropriate subobject of the ultimate actual argument /one_d_field/ the subprogram extract_vec was invoked with as long as /one_d_field/ remains allocated. Otherwise, the subroutine can be repeatedly invoked with /one_d_field/ allocated to a different dynamic type than before. For example, the following program program change_field_type use, intrinsic :: iso_c_binding implicit none : ! type definitions and object declarations from above real, pointer :: v1(:) allocate(one_d_field(3), & source = (/ scalar_vector( 1.0, (/ -1.0, 0.0, 1.0 /) ), & scalar_vector( 1.1, (/ -1.2, 0.2, 0.9 /) ), & scalar_vector( 1.2, (/ -1.4, 0.4, 0.8 /) ) /) ) call extract_vec(one_d_field, 1, v1, 2) print *, v1 deallocate(one_d_field) ! v1 becomes undefined allocate(one_d_field(1), & source = (/ scalar_vector_matrix( 1.0, (/ -1.0, 0.0, 1.0 /), & reshape( (/ 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, & 0.0, 0.0, 1.0 /), (/3, 3/) ) ) /) ) call extract_vec(one_d_field, 2, v1, 1) print *, v1 deallocate(one_d_field) ! v1 becomes undefined end program will print the two lines 0.0 0.2 0.4 -1.0"