ISO/IEC JTC1/SC22/WG5 N1870 Result of WG5 letter ballot on N1866 John Reid N1867 asked this question Please answer the following question "Is N1866 ready for forwarding to SC22 as the PDTR?" in one of these ways. 1) Yes. 2) Yes, but I recommend the following changes. 3) No, for the following reasons. 4) Abstain. The numbers of answers in each category were: 1 for 1) Yes. 5 for 2) Yes, but I recommend the following changes. 2 for 3) No, for the following reasons. 5 for 4) Abstain. The editor considered all the suggested changed and accepted most of them. The revised document is N1869. One of those voting no (Malcolm Cohen) said he was happy with N1869. I decided that consensus has been reached for submission of N1869 as the PDTR. Here are the responses in detail _______________________________________________________________________ Reinhold Bader: 2) Yes, but I recommend the following changes. (1) The PDF still contains a /Title entry with the value 11-146r1, as well as a /Subject entry which appears inappropriate. This should be fixed in the LaTeX source to say "TR29113" and "Type 2 Technical Report on Interoperability with C", respectively. (2) [v, para 6] After "Procedure", add "s" (Clause 3 has its heading correct) (3) [9:9] Remove the "s" at the end of "Arguments" (there is only one). (4) [11:15-16] Move line break to before CFI_ (5) [11:25] Before "CFI_", insert "with " (6) [12:12,14] Replace "equals" with "is equal to", twice; this appears more consistent with later wording. (7) [12:40] Replace "In a descriptor ... array" by "In a C descriptor whose attribute member has the value CFI_attribute_unknown_size," Reason: It is already explained elsewhere [14:2] what the attribute value means. (8) Looking at NOTE 5.3 I find I dislike it. It should, if present at all, rather point out what the general procedure on usage of the macro is. Here is a suggested replacement text: "NOTE 5.3 The CFI_CDESC_T macro is provided to support management of objects suitable for use in Fortran within C, in particular by providing the memory needed for the C descriptor itself. The address of an entity declared using the macro is not usable as an actual argument corresponding to a formal parameter of type *CFI_cdesc_t without an explicit cast." (Notes 5.7 and 5.8 give further information which therefore needs no coverage here). (9) Table 5.3 contains two error code macros, CFI_INVALID_EXTENT and CFI_INVALID_SM which appear to be superfluous because no arguments of type CFI_dim_t appear in the API any more. I therefore suggest to delete these two error codes, and correct the description of CFI_ERROR_OUT_OF_BOUNDS by replacing the text "A reference is out of bounds" by "A function argument is causing out-of-bounds references" Quite generally, the description of the error codes refers to the C descriptor instead of the function argument; this appears inappropriate or at least incomplete for some of them. (10) [16:21,22] After "allocatable" and "pointer" respectively, add "variable". (11) [17:27] After "dummy" add "=0" to suppress compiler grumble. (12) In the description of CFI_establish, we've unfortunately omitted the effect on the lower bounds if an associated pointer is established. Suggested edit: [18:34] after "contiguous array" add "; if the attribute argument has the value CFI_attribute_pointer, the lower bounds of the object described by /dv/ are set to zero" (13) In NOTE 5.7, replace "the descriptor" by "a descriptor" (14) NOTE 5.10 is not entirely correct. If the object is an unallocated allocatable variable, it appears to be processor dependent whether the object is contiguous. Suggested edit: Replace "or CFI_attribute_allocatable" by ", or which describes an allocated allocatable variable" (15) [21:5] Replace "source->dim[0].upper_bound" by "source->dim[0].lower_bound+source->dim[0].extent-1" (an upper_bound component does not exist) (16) [22:2] Replace "complex" by "_Complex" (17) [22:9] Replace "CFI_type_double_complex" by "CFI_type_double_Complex" (18) [25:4] In "braces .", delete the blank. (19) [34:22/24] It seems inappropriate to introduce paragraphs 6 and 7 at all in the places they are now. Suggestion: keep the whole section in para 5, and have para 6 start at [34:25]. ............................................ Malcolm Cohen: 3) No, for the following reasons. REASON 1. Line numbers should be turned off. REASON 2. Paragraph numbers really don't work throughout clause 6. Either paragraph numbering could be turned off entirely for the whole document, or the following changes made: Editorial: spurious paragraph numbers need to be deleted: 6.2 paragraph numbers 2, 4. 6.3 paragraph numbers 2, 3, 5, 7, 8. 6.4 paragraph numbers 3, 5. 6.6 paragraph number 3. 6.5 paragraph numbers 3, 4, 7, 9, 11, 14, 15, 16. 6.7 paragraph numbers 2, 4, 6, 8, 10, 12. 6.8 paragraph numbers 2, 4, 5, 7, 9, 11, 14, 16, 18-24, 26, 29, 31, 33, 35, 37, 39, 41. 6.9 paragraph numbers 2, 4, 6, 8, 10, 13, 14, 16, 17. 6.11 either delete paragraph 1 (not just the number) or delete paragraph numbers 2-4. REASON 3. Defective edit instructions need to be changed: [31:29] after "15.5.8" insert ", with the existing 15.5 to be renumbered 15.6 and its subclauses to be renumbered accordingly". Then, insert "Insert subclause 2.4.2 of this Technical Report at the very end of clause 15 where it will become 15.6.4.". [31:30] Delete REASON 4. Missing edit for assumed-rank. [28:8+] Insert new edit delimited by horizontal line "{Replace paragraph 2 of 12.4.3.4.5 with}" and then the contents from [12:12-15] of the TR, not including NOTE 2.3. REASON 5. PDF Author info should be "JTC 1/SC 22/WG 5" not "INCITS/PL22.3". REASON 6. Page size should be A4. REASON 7. The Introduction is not supposed have a subtitle: after "Introduction", delete subtitle "Techical ... C". REASON 8. [1:1-2] Replace the title with "Information technology - Programming languages - Fortran - Further Interoperability of Fortran with C". I think that there should not be a trailing "-" (yes, the standard itself got that wrong!). Also please ensure more significant space between the tital and "1 Overview", e.g. with \vspace{1cm} (blank line before and after that). You might need to push 1.4 off onto the next page to avoid a widow. REASON 9. [1:20,23] Delete angle brackets around "dummy variable" twice, to get the definition into the form required by ISO (it is supposed to be a drop-in replacement, which for a noun is a noun phrase not an adjectival one). REASON 10. The definition of assumed-type object is defective, as it makes CLASS(*) assumed-type. The only obvious safe fix is to replace it with "dummy variable declared with the TYPE(*) type specifier", unsatisfactory though that seems. REASON 11. The definition of C descriptor is a bit too terse, I recommend "C structure of type CFI_cdesc_t". In fact it would probably be good to change most or maybe all of the "struct" usage in text to "C structure" (unless the letter C is absolutely positively definitely redundant and it cannot be misinterpreted even by a perverse reading). REASON 12. NOTE 2.1 says "is passed as a simple pointer to the first address of the object" this is confusing and possibly wrong (C allows fat pointers UIUI). Anyway, a pointer *is* an address, it doesn't "point to" an address (unless it is a pointer to a pointer). And what is the "first address" of an object? Replace with "is intended to be passed as the C address of the object". Following that, change "there is insufficient" to "there would be insufficient". ................................................. Robert Corbett 3) No, for the following reasons. Before giving my reasons for voting no, I want to say that the current draft is much better than the draft produced at the February meeting. Robert Corbett representing Oracle America ---------------------------- 1. The specification of the extended usage of the ASYNCHRONOUS attribute given in Clause 2.4 puts new restrictions on programs, but does not put new restrictions on processors. I believe that new restrictions on processors were intended, but they are not stated. A statement should be added to the effect that the value of a pending communication affector should be regarded as being defined or redefined by execution of an asynchronous communication completion procedure. 2. The specification of the function CFI_allocate states that "dv shall point to a C descriptor describing the object." I assume that the object to which that statement refers is the object to be allocated. I presume that members base_addr, elem_len, and dim need not describe the object being allocated before the call of CFI_allocate is successfully completed. The specification of CFI_allocate should state which fields of the C descriptor must be valid before CFI_allocate is called. The description of CFI_allocate should state which members of the C descriptor referenced by dv are updated if the allocation is successful. 3. The description of CFI_deallocate should state which members of the C descriptor referenced by dv are updated. My guess is that only the member base_addr needs to be updated. A processor might also be allowed to update the members elem_len and dim. 4. The macro CFI_MAX_RANK assumes that processors have fixed maximum ranks. That might be true of all modern Fortran processors. However, I have used older compilers that imposed no fixed limit on the rank of arrays. I propose that the macro CFI_MAX_RANK be left undefined if the processor has no fixed limit on the rank of arrays. 5. The definition of the type CFI_index_t is not a good choice. I have used compilers on machines with 16-bit address spaces that allowed array bounds in the range of 32-bit signed integers. I have used compilers on 32-bit machines that allowed array bounds in the range of 64-bit signed integers. The definition of the type CFI_index_t should be a signed integer type capable of representing the lower bound of an array in the Fortran processor. 6. The type of the member extent of the C structure type CFI_dim_t should be an unsigned integer type that is at least as large as a size_t. I propose that the value of dim[r-1].extent for a rank r assumed-size array be the maximum value of that unsigned integer type. 7. The type of member sm of the C structure type CFI_dim_t should be a signed integer type that is at least as large as a ptrdiff_t. 8. The DPTR should simply state what the correspondence is between the elements of the member dim of the C structure type CFI_cdesc_t and the order of Fortran bounds and subscripts. Paragraph 3 of Clause 5.3.3 forces the order to be column major, but not in a way that is easily understood. 9. The prohibition against explicit-shape arrays of class TYPE(*) is harmful. Regardless of Note 2.1, there is a functional difference between an explicit-shape array of class TYPE(*) and an assumed-size array of class TYPE(*). Consider the following code fragment SUBROUTINE CALLER(P) INTEGER, POINTER :: P(:) INTERFACE SUBROUTINE CALLEE(A) BIND(C) TYPE(*), DIMENSION(9) :: A END SUBROUTINE END INTERFACE CALL CALLEE(P) END One implementation of the call of CALLEE would make copy of the first nine elements of the array referenced by P before the call and copy the elements back after the call. If the array A were assumed-size, a similar implementation would need to make a copy of the entire array referenced by P. 10. The definition of "assumed-type object" given in Clause 1.3.2 is deficient. It does not match the definition given in Clause 2.1. At the very least, it should say whose dynamic type and type parameters are assumed from its effective argument 11. The use of the term "struct" throughout the DPTR is a bit jarring. The C standard uses the full word "structure." .......................................................... Bill Long: 2) Yes, but I recommend the following changes. The front page should add the title of the TR, "Further Interoperability of Fortran with C" and indicate it is the draft for the PDTR ballot. .......................................................... Nick Maclaren: 4) Abstain. .......................................................... Toon Moene: 1) Yes. I have no further suggestions than those put forward by John Reid, Bill Long and Reinhold Bader. .......................................................... David Muxworthy: 4) Abstain Because of holidays I have not had chance to read N1866 in detail. I agree that as an SC22 document it needs a different title page and I agree with many of Reinhold's editorial comments. .......................................................... Dan Nagle: 2) Yes, but I recommend the following changes. I am generally agreeable to the editorial suggestions made so far. .......................................................... John Reid: 2) Yes, but I recommend the following changes. There are many places where "descriptor" rather than "C descriptor" is used. I recommend that each be considered for being changed to "C descriptor". .......................................................... Van Snyder: 2) Yes, but I recommend the following changes. [1:26+2 Note 1.1] Replace "an object" by "a Fortran object". [4:4 2.2p3] Should be a note. [4:15+5 Note 2.3] Replace "component" by "member". [4:17-18 2.3p1] This paragraph is unnecessary. It could be a note before (or part of) Note 2.4. [7:12 3.3p1] Replace "value" by "values". [9:3 4.1p1] Insert "subclause" before "4.2". [12:13 5.3.3p1] Insert "and kind" after "scalar of the character type" [13:7+2 Note 5.3] Insert a cross referece after "CFI_deallocate". [16:5 5.3.5.1p4] Replace "accessed" by "referenced". [16:7 5.3.5.1p5] Replace "this subclause" by "subclause 5.3.5" or "subclauses of subclause 5.3.5". There are no function definitions in subclause 5.3.5.1. [16:11 5.3.5.1p6] Insert "subclause" before "5.3". [16:13 5.3.5.1p6] Insert "subclause" before "5.3.4". [16:14 5.3.5.1p6] Insert "subclause" before "5.3.5". [16:19 5.3.2p1] Insert "C" before "address". [16:26 5.3.2p3] Insert "C" before "address". [16:28 5.3.2p3] Insert "C" before "address". [16:31 5.3.2p5] Insert "C" before "address". [16:30+ 5.3.5.3p7+] A note would be illuminating: "NOTE 5.6a This is equivalent to the Fortran statement ALLOCATE ( A(100,100), STAT=IND ) " [17:13 5.3.5.3p2] Insert "and kind" after "scalar of the character type". [18:10+ 5.3.5.4p7+] A note would be illuminating: "NOTE 5.6a This is equivalent to the Fortran statement DEALLOCATE ( A, STAT=IND ) " [18:19 5.3.5.5p2] Replace "base" by "C" or insert "C" before "base". [18:28 5.3.5.5p2] Insert "and kind" after "scalar of the character type" [20:14 5.3.5.7p2] Insert either "Fortran" or "C" before "subscripts" ([21:5] suggests "C"). [20:17 5.3.5.7p2] Replace "be" by "not be less than" or "be greater than or equal to". [20:18 5.3.5.7p2] Insert either "Fortran" or "C" before "subscripts" ([21:5] suggests "C"). [20:21 5.3.5.7p2] Replace "be" by "not be less than" or "be greater than or equal to". [20:24 5.3.5.7p2] Insert either "Fortran" or "C" before "subscripts" ([21:5] suggests "C"). [20:25 5.3.5.7p2] Replace "be" by "not be less than" or "be greater than or equal to". [21:24-25 p.3.5.8p2] Replace "base" by "C" or insert "C" before "base" at least the first time, and maybe thrice. [21:30 5.3.5.8p2] Insert "and kind" after "scalar of the character type". [22:14 5.3.5.9p1] Insert "to" before "be". [22:20 5.3.5.9p2] Replace "in same" by "the same". [22:23 5.3.5.9p2] Insert "Fortran subscripts for the" or "C subscripts for the" before "lower bounds". [22:35 5.3.5.9p7] Something other than "this" would be more illuminating. Maybe "the same array". [22:41 5.3.6p1] Is "calling" the correct term in the C context? Maybe "invoking" would be better. [23:12 5.3.7p2] Replace "a call to" by "an invocation of" or "reference to". [23:14 5.3.7p2] Replace "call" by "invocation" or "reference". Using "call" in 5.3.7p3 is appropriate. [31:32 6.10p1] Delete "two". [26:2 6.3p8] Does this need a caveat concerning RANK, or does 1539-1:2010:1.6.1p1 cover it? [26:15 6.4p5 C407b] Replace "intrinsic and" by "intrinsic or". [26:23 6.5p16] Should be a note, since it doesn't exclusively apply to assumed-rank entities. [27:29 6.6p3] Is "call" the correct C term? Should it be "reference" or "invocation"? [28:5-6 6.7p2] It is also a characteristic that these rank, shape, size, type, or type parameters are not assumed. The sentence ought to be "Whether a rank, shape, size, type, or type parameter is assumed or deferred is a characteristic." [28:11 6.7p6] Insert "of" before "assumed type". [29:10 6.8p14] It is redundant to begin a note with "Note that". Replace "Note that if" by "If". [29:30 6.8p29] It is redundant to begin a note with "Note that". Replace "Note that if" by "If". [30:11 6.8p39] It is redundant to begin a note with "Note that". Replace "Note that if" by "If". .......................................................... Masayuki Takata: 4) Abstain. I hope the quality of the draft is ready for PDTR ballot, which allows substantial number of editorial and minor changes with a smaller number of major changes. But I had not have enough time to review it. .......................................................... Stan Whitlock: 4) Abstain. .......................................................... Jim Xia: 4) Abstain. My concern is that introduction of assumed-type and assumed-rank dummy arguments further complicates the situation in the area of argument association. There isn't enough time to study the possible pitfalls in using these different type of arguments in complicate call chains. I certainly didn't have time to go through all the possible permutations.