J3/13-313 To: J3 Members From: Stan Whitlock Subject: Results of the J3 Fortran interp letter ballot #29 Date: 2013 September 0 Here are the results of J3 letter ballot #29 on Fortran interpretations that officially closed 9-Aug-2013. The ballot is in J3 paper 13-297 for meeting #202. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F08 F08 F08 F08 F08 F08 F08 F08 / interp 091 092 093 094 095 096 097 098 result of LB #29 C C C Y Y C Y Y Dan Chen C Y Y Y Y Y Y Y Malcolm Cohen C C C Y Y Y Y Y Robert Corbett C C N Y C Y Y Y Bill Long C C C Y Y C Y Y Karla Morris Dan Nagle Y Y Y Y Y Y Y Y Van Snyder Y C Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y where Y means "yes" C "yes with comment" N "no with comment" The comments for each interp are attached below in the same order as the table above. The comments for each interp are separated by a line of "*"s. The interps marked "C" pass with some minor fixes, as noted below. The interps marked "N" fail. The edited interps in their final form are attached and will appear in the next version 006A. /Stan ************************************************************************ F08/0091 Derived type with no components Daniel Chen's Yes vote with comment on F08/0091: The comment is for Q1/A1. On the system that an object of an empty derived type does not occupy any storage, should the result of ASSOCIATED intrinsic as in the test case m7_1 returns FALSE to truthfully reflect the fact that there is not an association that has been established? If so, should we add another case in p5 of 13.7.16 "If TARGET is an object of an empty derived type, the result is processor dependent." in 13.7.16? Malcolm Cohen's Yes vote with comment on F08/0091: Agree with Bill Long re swapping x and y in m7_1 and m7_2. Instead of adding a new constraint, it might be better just to add the condition to the existing constraint, i.e. [62:19] After "appears," insert "the type shall have at least one component,". Robert Corbett's Yes vote with comment on F08/0091: I agree with Bill that the references to the intrinsic function Associated should be fixed. Bill Long's Yes vote with comment on F08/0091: In programs m7_1 (for Q1) and m7_2 (for Q2) the references to the associated intrinsic need to have a pointer for the first argument. Change "Associated(x,y)" to "Associated(y,x)" twice. It might be better to insert the Edit at [62:18+] so that the new constraint appears before the exiting C436. In that order, the constraint that a component exists comes before the one that places limits on the components. Result for F08/0091: Accept Bill Long's changes for m7_1 and m7_2. Accept Malcolm Cohen's change to [62:19]. We will not address Daniel Chen's comment in the context of this interp. According to the standard, there is no such thing as an empty type that occupies no storage unit. If Daniel wants a change, he should submit a new interp request. F08/0091 passed as amended by J3 letter ballot. F08/0092 Derived type parameter requirements Malcolm Cohen's Yes vote with comment on F08/0092: Agree with Van Snyder and Bill Long re "be" and "64:9"->"64:8". I don't think "given" is really necessary: we do not consistently use "given" in other similar constraints. Robert Corbett's Yes vote with comment on F08/0092: The word "given" should be added before "" in the text of constraint C427a. Constraint C427 uses "given". Failing to use "given" in the new constraint might prove confusing. Bill Long's Yes vote with comment on F08/0092: I agree with Van's change "to valid" to "to be valid". The edit [64:9] should be at [64:8]. Van Snyder's Yes vote with comment on F08/0092: For the archive, insert "be" before "valid" in the first line of text after the code in the question. Result for F08/0092: Accept Van Snyder's insertion of "be" before "valid". Accept Bill Long's change [64:9] to [64:8]. F08/0092 passed as amended by J3 letter ballot. F08/0093 Process exit status and error termination Malcolm Cohen's Yes vote with comment on F08/0093: Agree with Bill Long re insertion of a cross-reference. This interp does not modify our recommendation of zero, nor do I think it is necessary to modify it. Unlike the situation for exit(0) in C99, this is only a recommendation, not a requirement. Robert Corbett's No vote on F08/0093: The word "at" in the edit proposed for [188:10+11+] should be "as". The question correctly points out that on some systems the exit code that indicates successful execution is not zero. There are also systems where the difference between successful execution and abnormal termination is indicated by which system call is used to terminate execution. The edits should either be modified to accommodate more general means of indicating whether execution was successful or unsuccessful, or they should state that they apply only to systems that use the value zero to indicate successful termination. The definition of the function exit in the C99 standard does not say that \bf{exit(0)} returns a status with the value zero. It says If the value of \bf{status} is zero or \bf{EXIT_SUCCESS}, an implementation-defined form of the status \it{successful termination} is returned. Bill Long's Yes vote with comment on F08/0093: At the end of the edit at [460:24+] insert "(2.3.5)", as the other paragraphs in this Annex include citations at the end. Result for F08/0093: Accept Robert Corbett's change in [188:10+11+]. Accept Bill Long's change in [460:24+]. F08/0093 passed as amended by J3 letter ballot. F08/0094 Procedure statement and double colon Result for F08/0094: Passed by J3 letter ballot F08/0095 Is PRESENT allowed in specification and constant expressions Robert Corbett's Yes vote with comment on F08/0095: The edits are fine as far as they go. However, the intrinsic functions ALLOCATED and ASSOCIATED present problems similar to those of PRESENT. Those problems should also be addressed. Malcolm Cohen's comment on Robert Corbett's comment on F08/0095: I see no problem. The properties being tested by ALLOCATED and ASSOCIATED are clearly "deferred": just like the shape of an allocatable array, whether it is allocated or not is determined by execution of ALLOCATE (and DEALLOCATE) statements etc. Clarifying this would be an editorial improvement: we don't need to wheel out the big guns of interpretation. That would be an overreaction to withdraw 0095. 0095 is fixing stuff that is actually ambiguous or wrong. Improving the exposition w.r.t. ALLOCATED and ASSOCIATED is a good idea, but does not warrant leaving PRESENT actually broken for 6-12 months. Result for F08/0095: No changes were made. F08/0095 passed by J3 letter ballot. F08/0096 Is VALUE permitted for an array in a BIND(C) procedure? Bill Long's Yes vote with comment on F08/0096: The first edit modifies C1255. Separately, TS 29113 replaces this same constraint. This is just a reminder note that these changes need to be coordinated. Result for F08/0096: Bill long's suggested note was added. F08/0096 passed as amended by J3 letter ballot. F08/0097 Is the optional comma allowed in TYPE(CHARACTER*...)? Result for F08/0097: Passed by J3 letter ballot F08/0098 How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt? Result for F08/0098: Passed by J3 letter ballot ************************************************************************ ------------------------------------------------------------------------ NUMBER: F08/0091 TITLE: Derived type with no components KEYWORD: Derived type DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1. Consider Program m7_1 Type empty End Type Type(empty),Target :: x Type(empty),Pointer :: y y => x Print *,Associated(y,x) End Is this program standard-conforming, and does it print T or F? According to 16.5.3.2p2, item 1 is default integer etc, N/A item 2 is double precision etc, N/A item 3 is default character, N/A item 4 is C character, N/A item 5 is SEQUENCE type, N/A According to item (6), "a nonpointer scalar object of any type not specified in items (1)-(5) occupies a single unspecified storage unit that is different [from everything else]" If that analysis is correct, X occupies a single unspecified storage unit, not zero storage units, and therefore T should be printed. Q2. Consider Program m7_2 Type sempty Sequence End Type Type(sempty),Target :: x Type(sempty),Pointer :: y y => x Print *,Associated(y,x) End Is this program standard-conforming, and does it print T or F? Now X falls into item 5, which makes it a "sequence of storage sequences corresponding to the sequence of its ultimate components"; there are no ultimate components, this makes it a zero-sized storage sequence and therefore F should be printed. This does not seem to be consistent with the apparent answer to Q1. Q3. Consider Program m7_3 Type numeric_empty Sequence End Type Type character_empty Sequence End Type Type(numeric_empty) a Integer b Character c Type(character_empty) d Equivalence(a,b) ! E1. Equivalence(c,d) ! E2. End Is this program conforming? According to the definitions in 4.5.2.3, NUMERIC_EMPTY is a numeric sequence type and therefore one might expect to be able to EQUIVALENCE it to an INTEGER. Similarly, CHARACTER_EMPTY is a character sequence type and therefore one might expect to be able to EQUIVALENCE it to a CHARACTER. However, NUMERIC_EMPTY is clearly also a character sequence type, and therefore statement E1 violates C592 because B is not character or character sequence. Similarly, CHARACTER_EMPTY is clearly also a numeric sequence type, and therefore statement E2 violates C591. It seems very strange to have a type that is simultaneously numeric and character sequence type. Q4. Consider Program m7_4 Type numeric_empty_2 Sequence Real c(0) End Type Type character_empty_2 Sequence Character(0) c End Type Type(numeric_empty_2) a Integer b Character c Type(character_empty_2) d Equivalence(a,b) ! E3. Equivalence(c,d) ! E4. End Does this program conform? According to the definitions in 4.5.2.3, NUMERIC_EMPTY_2 is a numeric sequence type and not a character sequence type, and conversely CHARACTER_EMPTY_2 is a character sequence type and not a numeric sequence type, and therefore the constraints for the statements at E3 and E4 are not violated. Thus this appears to be conforming, in contradiction to the example in Q3, even though the storage sequence of NUMERIC_EMPTY, NUMERIC_EMPTY_2, CHARACTER_EMPTY, and CHARACTER_EMPTY_2 are all the same. This does not look very consistent with the situation in Q3. ANSWER: A1. The program is conforming and prints T. A2. The program was not intended to conform; SEQUENCE makes no sense when there are no components. An edit is needed to correct this. A3. The program does not conform as a sequence type must have at least one component. A4. The program is conforming. The apparent design inconsistency is not an error in the standard. EDIT to 10-007r1: [62:19] 4.5.2.3, in constraint C436 After "appears," insert "the type shall have at least one component,". SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-266 F08/0091 submitted m201 13-266r1 Revised - passed by J3 meeting m202 13-xxx Passed as amended by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0092 TITLE: Derived type parameter requirements KEYWORD: Derived type parameter DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Type t1(a,a) Integer,Kind :: a Integer,Len :: a End Type Type t2(a) Integer,Kind :: a,a,a End Type These type definition appears to valid, in that (a) there is no requirement that a type parameter appears only once in the ; (b) there is no requirement that a type parameter appears in only one , and only once. Were these intended to be valid? What is their meaning? ANSWER: These were not intended to be valid, and they are not valid because the standard does not establish an interpretation for them. Unique names for type parameters can possibly be deduced from the scoping rules. Edits are supplied to make the requirements explicit. EDITS to 10-007r1: [61:19+] In 4.5.2.1, after C427 insert new constraint "C427a (R426) The same shall not appear more than once in a ." {Require unique names for type parameters.} [64:8] In 4.5.3.1, C438, after "shall appear" insert "exactly once". {Forbid multiple declarations of a type parameter, whether in the same or more than one.} SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-267 F08/0092 submitted - passed by J3 meeting m202 13-xxx Passed as amended by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0093 TITLE: Process exit status and error termination KEYWORD: ERROR STOP DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Many operating systems today (e.g. Posix-related ones) use a process exit status of zero to indicate successful execution, whereas nonzero indicates an error. (Occasionally nonzero values, e.g. 1, also indicate success.) Fortran STOP and ERROR STOP with an integer are recommended to use the as the exit status. The STOP statement without an integer is recommended to have an exit status of zero; this conforms to common practice since STOP initiates normal termination. The standard is silent on the effect of error termination, except in the case of an ERROR STOP (sans integer ) which is unexpectedly recommended to also return an exit status of zero. Q1. Is this intentional? Should the exit code for ERROR STOP not have been recommended to be nonzero? Q2. Should the recommendation for an ERROR STOP not also apply to error termination by other causes? ANSWER: A1. It was not intended to recommend returning "success" for error termination. An edit is supplied to correct this. A2. Yes, the recommendation for an ERROR STOP without an integer should also apply to other means of standard-defined error termination. An edit is supplied to correct this omission. EDIT to 10-007r1: [33:36+] 2.3.5, before Note 2.7, insert new note "NOTE 2.6a If the processor supports the concept of a process exit status, it is recommended that error termination initiated other than by an ERROR STOP statement supplies a processor-dependent nonzero value as the process exit status." {Recommendation for error termination other than by ERROR STOP.} [188:10+10] In 8.4, Note 8.30, Before "is of type character or does not appear" Insert "in a STOP statement". {Limit zero recommendation to STOP, not ERROR STOP.} [188:10+11+] At the end of Note 8.30, insert new paragraphs "If the in an ERROR STOP statement is of type character or does not appear, it is recommended that a processor-dependent nonzero value be supplied as the process exit status, if the processor supports that concept." {Specify nonzero exit for ERROR STOP.} [460:24+] Annex A, after "STOP or ERROR STOP" insert new bullet "the recommended process exit status when error termination is initiated other than by an ERROR STOP statement with an integer (2.3.5);" {Probably unnecessary, seeing how it is only a recommendation, but maybe a good idea anyway.} SUBMITTED BY: Bill Long/Malcolm Cohen HISTORY: m201 13-268 F08/0093 submitted - passed by J3 meeting m202 13-xxx Passed as amended by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0094 TITLE: Procedure statement and double colon KEYWORD: PROCEDURE, Interface block DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Fortran 2003 did not permit a double colon in the in an interface block. Fortran 2008 syntax seems to allow this, but it is not mentioned in the Introduction as a new F2008 feature. Is this apparent new feature deliberate? ANSWER: Yes, this new feature was intended. An edit is provided to add mention of it to the Introduction. EDIT: [xvi] Introduction, p2, "Programs and procedures:" bullet, After "empty CONTAINS section is allowed." Insert "A PROCEDURE statement can have a double colon before the first procedure name." SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-274 F08/0094 submitted - passed by J3 meeting m202 13-xxx Passed by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0095 TITLE: Is PRESENT allowed in specification and constant expressions KEYWORD: PRESENT, optional dummy argument DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1. Consider Subroutine s1(a) Integer,Optional :: a Logical,Parameter :: x = Present(a) Print *,x End Subroutine Does this program unit conform to the standard? 7.1.12 item (4) permits "a specification inquiry where each designator or function argument is ... (b) a variable whose properties inquired about are not (i) assumed, (ii) deferred, or (iii) defined by an expression that is not a constant expression," PRESENT is a specification inquiry (because it is an intrinsic inquiry function), and the standard does not say that the "presence" of an optional dummy argument is an assumed or deferred attribute, and it does not appear to be "defined by an expression" either. On the other hand, the standard does not say anything about what kind of property the presence is. Q2. Consider Subroutine s2(a) Integer,Optional :: a Real x(Merge(2,3,Present(a))) If (Present(a)) Then x = [ 1,2,a ] Else x = [ 1,2 ] End If Print *,x End Subroutine Does this program unit conform to the standard? It appears to satisfy the rules for specification expression, similarly to how it satisfies the rules for a constant expression, but then the standard is silent as to what sort of property "presence" is... Q3. Consider Subroutine s3(a) Character(*),Optional :: a Real x(Len(a)) Print *,Size(x) End Subroutine Does this program unit conform to the standard? Using the same reasoning as Q1 and Q2, it appears to conform, but if A is absent, LEN(A) is not permitted by 12.5.2.12. ANSWER: A1. Program unit S1 was not intended to conform to the standard. An edit is provided to clarify that this is not valid. A2. Program unit S2 was intended to conform to the standard. An edit is provided to clarify that this is valid. A3. Program unit S3 was not intended to conform to the standard. An edit is provided to clarify that this is not valid. EDITS to 10-007r1: [150:24] 7.1.11p2, item (9)(b) after "variable" insert ",that is not an optional dummy argument, ". {Prevent specification enquiries on optional dummy arguments.} [150:27+] 7.1.11p2, after item (9) entirely, insert "(9a) a specification inquiry that is a constant expression, (9b) a reference to the intrinsic function PRESENT," {Allow inquiries on optional dummy arguments that will not violate the rules in 12.5.2.12 when the dummy is absent, and allow PRESENT to be used.} [150:37] 7.1.11p4, item (1) after "intrinsic inquiry function" insert "other than PRESENT". {Remove PRESENT from list of specification inquiries, this fixes constant expressions.} SUBMITTED BY: Malcolm Cohen/Van Snyder HISTORY: m201 13-278 F08/0095 submitted m201 13-278r1 Passed by J3 meeting m202 13-xxx Passed by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0096 TITLE: Is VALUE permitted for an array in a BIND(C) procedure? KEYWORD: array, BIND(C), VALUE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider INTERFACE SUBROUTINE s(a) BIND(C) USE ISO_C_BINDING REAL(C_float),VALUE :: a(100) END END INTERFACE Q1. Does this interface conform to the Fortran standard? Q2. If so, what prototype does it interoperate with? ANSWER: A1. C does not have arrays that are passed by value, so this was not intended to conform to the Fortran standard. An edit is provided to clarify this. A2. This question is moot. EDITS to 10-007r1: [306:31] 12.6.2.2, C1255, after "(15.3.5, 15.3.6)" insert "that is not an array with the VALUE attribute," {Do not permit BIND(C) to have arrays by value.} {Note: TS 29113 replaces this same constraint.} [433:12] 15.3.7p2, item (4), after "any" insert "scalar". {Do not describe arrays by value in a prototype.} SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-284 F08/0096 submitted - passed by J3 meeting m202 13-xxx Passed as amended by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0097 TITLE: Is the optional comma allowed in TYPE(CHARACTER*...)? KEYWORD: TYPE, CHARACTER DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider CHARACTER*1, A TYPE(CHARACTER*1,) B The optional comma in the declaration of B looks ugly. Is this deliberate? ANSWER: No, this syntax was inadvertently allowed. An edit is provided to remove it. EDITS to 10-007r1: [51:26+] 4.3.1.1, after C406, insert new constraint "C406a (R403) In TYPE() the shall not end with a comma." SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-285 F08/0097 submitted - passed by J3 meeting m202 13-xxx Passed by J3 letter ballot 13-297 ---------------------------------------------------------------------- NUMBER: F08/0098 TITLE: How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt? KEYWORD: LOCK DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider LOCK ( x, ACQUIRED_LOCK=n1, ACQUIRED_LOCK=n2, STAT=n3, STAT=n4 ) Is this conforming? Multiple STAT= are prohibited from a , but this is a so that does not apply. There is no constraint anywhere about how many ACQUIRED_LOCK= specifiers may appear. ANSWER: No, this was not intended to be conforming. No specifier was intended to be allowed to appear more than once. EDITS to 10-007r1: [194:2+] 8.5.6, after R864, insert new constraint "C852a No specifier shall appear more than once in a given ." SUBMITTED BY: Malcolm Cohen HISTORY: m201 13-286 F08/0098 submitted - passed by J3 meeting m202 13-xxx Passed by J3 letter ballot 13-297 ----------------------------------------------------------------------