From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Sep 24 20:53:57 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id D60D235730F; Tue, 24 Sep 2013 20:53:57 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-1-a-1.mail.uk.tiscali.com (mk-filter-1-a-1.mail.tiscali.co.uk [212.74.100.52]) by www.open-std.org (Postfix) with ESMTP id 8588A357233 for ; Tue, 24 Sep 2013 20:53:43 +0200 (CEST) X-Trace: 11138232/mk-filter-1.mail.uk.tiscali.com/B2C/$THROTTLED_STATIC/TalkTalk_Customer/2.101.16.77/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 2.101.16.77 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: XX/UNKNOWN X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAPbeQVICZRBN/2dsb2JhbAANTY0XuQmDcyU9FhgDAgECAUsNBgICsS6KDokTjhMLhVcDkCaBL4JKg12GHo5+gWg X-IPAS-Result: ApMBAPbeQVICZRBN/2dsb2JhbAANTY0XuQmDcyU9FhgDAgECAUsNBgICsS6KDokTjhMLhVcDkCaBL4JKg12GHo5+gWg X-IronPort-AV: E=Sophos;i="4.90,972,1371078000"; d="txt'?scan'208";a="11138232" Received: from host-2-101-16-77.as13285.net (HELO [127.0.0.1]) ([2.101.16.77]) by smtp.tiscali.co.uk with ESMTP; 24 Sep 2013 19:53:42 +0100 Message-ID: <5241DFC1.1010902@stfc.ac.uk> Date: Tue, 24 Sep 2013 19:53:53 +0100 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: WG5 Subject: WG5 letter ballot 7 on Fortran 2008 interpretations Content-Type: multipart/mixed; boundary="------------060209070704040703050704" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------060209070704040703050704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG5, Here is the final letter ballot for interpretations whose edits will be included in Corrigendum 3. These are the eight interpretations that were successful in the recent J3 ballot. The dealine for voting is 0900 UK time on Monday, 28 October 2013. Cheers, John. --------------060209070704040703050704 Content-Type: text/plain; charset=windows-1252; name="N1991.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1991.txt" ISO/IEC JTC1/SC22/WG5 N1991 Interps ready for WG5 ballot Stan Whitlock, 14-Sep-2013 As a result of J3 Fortran interp letter ballot #29 {13-313}, the following 8 F2008 interps are ready for WG5 ballot. ------------------------------------------------------------------------ Yes No Number Title --- --- F08/0091 Derived type with no components --- --- F08/0092 Derived type parameter requirements --- --- F08/0093 Process exit status and error termination --- --- F08/0094 Procedure statement and double colon --- --- F08/0095 Is PRESENT allowed in specification and constant expressions --- --- F08/0096 Is VALUE permitted for an array in a BIND(C) procedure? --- --- F08/0097 Is the optional comma allowed in TYPE(CHARACTER*...)? --- --- F08/0098 How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt? ---------------------------------------------------------------------- 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-313 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-313 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-313 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-313 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-313 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-313 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-313 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-313 Passed by J3 letter ballot 13-297 ---------------------------------------------------------------------- --------------060209070704040703050704 Content-Type: text/plain; charset=windows-1252; name="N1992.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1992.txt" ISO/IEC JTC1/SC22/WG5 N1992 WG5 letter ballot 7 on Fortran 2008 interpretations John Reid, 24 September 2013 This is the seventh WG5 vote on a set of draft interpretations for Fortran 2008. They have all been approved in a J3 letter ballot. The rules we operate on say: --- --- 4. The chair of J3/interp gathers all interp answers that are marked "passed by J3 letter ballot" and forwards them to the WG5 convenor. The WG5 convenor holds a ballot of individual members; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. The answers that pass this ballot become "WG5 approved". J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 5. "WG5 approved" answers are processed into a corrigendum document by taking the edits from the interp answers and putting them in the format required by ISO. A WG5 vote is made on forwarding the corrigendum to SC22. The following Fortran 2008 interpretations are being balloted: Yes No Number Title --- --- F08/0091 Derived type with no components --- --- F08/0092 Derived type parameter requirements --- --- F08/0093 Process exit status and error termination --- --- F08/0094 Procedure statement and double colon --- --- F08/0095 Is PRESENT allowed in specification and constant expressions --- --- F08/0096 Is VALUE permitted for an array in a BIND(C) procedure? --- --- F08/0097 Is the optional comma allowed in TYPE(CHARACTER*...)? --- --- F08/0098 How many ACQUIRED_LOCK= specifiers are allowed in a LOCK stmt? The text of these interpretations is in N1991. Each interpretation starts there with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send to sc22wg5@open-std.org by 0900 UK time on Monday, 28 October 2013, in order to be counted. Thanks, John. --------------060209070704040703050704--