ISO/IEC JTC1/SC22/WG5 N1711 WG5 letter ballot 4 on Fortran 2003 interpretations John Reid, 30 January 2008 This is the fourth set of draft interpretations for Fortran 2003. 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 2003 interpretations are being balloted: Yes No Number Title --- --- F03/0049 Separators in list-directed output involving UDDTIO --- --- F03/0050 Questions about internal files --- --- F03/0086 Elemental and BIND(C) --- --- F03/0088 Defined operations/assignments and VOLATILE/ASYNCHRONOUS --- --- F03/0089 Interoperability of non-BIND derived types --- --- F03/0092 Procedure characteristics and unlimited polymorphic --- --- F03/0093 Allocatable array on intrinsic assignment with scalar expr --- --- F03/0094 Final subroutine and VALUE attribute --- --- F03/0095 Bounds remapped pointer assignment and ASSOCIATED --- --- F03/0097 Blanks as separators in NAMELIST input --- --- F03/0098 Does allocate with source= define subcomponents? --- --- F03/0101 Is UDDTIO output suitable for namelist and list-directed input The text of these interpretations is attached. Each interpretation starts 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 only the above text {not this entire mail mail message} to sc22wg5@open-std.org by 8 a.m (UK time) on Friday, 29 February 2008, in order to be counted. Thanks, John. ====================================================================== NUMBER: F03/0049 TITLE: Separators in list-directed output involving UDDTIO KEYWORDS: list-directed output, separators, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER i END TYPE INTERFACE WRITE(FORMATTED) MODULE PROCEDURE formattedWriteT END INTERFACE CONTAINS SUBROUTINE formattedWriteT(dtv, unit, iotype, v_list, iostat, iomsg) CLASS(t), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg WRITE(unit, *) dtv%i, 'a' END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: t1 = t(5) OPEN(10, FILE='foo.txt', ACCESS='SEQUENTIAL', FORM='FORMATTED', & DELIM='NONE') WRITE(10, *), 'xyz', t1, 'zyx' END PROGRAM 10.9.2 of Fortran 2003 states that character sequences produced for list-directed output are not separated from each other by value separators when the delimiter mode is NONE. The implication of this is obvious when the adjacent effective output list items are both of character type. But when user-defined derived-type input/output is involved, it is much less clear whether a separator should be included in the output. In the example given, it is unclear whether the output should be: xyz 5 azyx or: xyz 5 a zyx 1. Should a separator be inserted between two non-delimited character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where both statements are list-directed? 2. Should a separator be inserted between two non-delimited character sequences when the character sequences are written by two different child data transfer statements, where both statements are list-directed? 3. Should a separator be inserted between two character sequences when one of the character sequences is written by a child data transfer statement, and the other is written by a parent data transfer statement, where one of the statements is list-directed and the other is format-directed? 4. Should a separator be inserted between two character sequences when the character sequences are written by two different child data transfer statements, where one of the statements is list-directed and the other is format-directed? ANSWER: 1) No. It is the intent of the standard (10.9.2) that when both the parent and child data transfer statements are both list-directed output statements, or both are namelist output statements, the processor treats the first list item appearing in a child data transfer statement as if that list item had immediately followed the last list item processed by the parent data transfer statement, as long as no other data transfers to that unit occurred in between the processing of those two list items. Therefore, in this case, the two character sequences are considered adjacent. 2) No. It is the intent of the standard (10.9.2) that when two different child data transfer statements are both list-directed output statements, or both namelist output statements, they write to the same unit, and no other data transfers to that unit occur in between the two child data transfer statements, the processor treats the first list item appearing in the second child data transfer statement as if that list item had immediately followed the last list item processed by the first child data transfer statement. Therefore, in this case, the two character sequences are considered adjacent. 3) It is processor dependent whether or not a separator appears between two such character sequences. In section 10.9.2, the phrase "adjacent undelimited character sequences" refers to character sequences produced by list-directed output. When one of the sequences is written by a child or parent output statement that is not list-directed, the exception described in the first paragraph of 10.9.2 does not apply. The other rules for inserting optional blanks around values in list-directed output allow the processor to insert optional leading and trailing blanks around a list item. The standard does not specify when optional blanks are written; therefore, when two adjacent list items (the values thereof) are written to an output record, and only one of them was written by list-directed input/output, the standard does not specify whether or not any optional blanks appear between those values in the output record. 4) It is processor dependent whether or not a separator appears between two such character sequences. See answer 3. EDITS: [241:5+] In Section 10.9.2, add the following to the end of the first paragraph: "Two undelimited character sequences are considered adjacent when both were written using list-directed input/output, no intervening data transfer or input/output file positioning operations occurred, and both were written either by a single data transfer statement, or during the execution of a parent data transfer statement along with its child data transfer statements." SUBMITTED BY: Rob James HISTORY: 05-140 m171 F03/0049 Submitted 05-140r1 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 06-367r1 m178 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0050 TITLE: Questions about internal files KEYWORDS: internal file, data transfer DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTIONS: Question 1: Fortran 2003 does not seem to prohibit this kind of recursive internal input/output. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m1 CHARACTER(20) :: ifile = '' CONTAINS CHARACTER(3) FUNCTION foo() WRITE(ifile, *) 'QWERTY' foo = 'abc' END FUNCTION END MODULE PROGRAM ex1 USE m1 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile END PROGRAM Question 2: Fortran 2003 does not seem to prohibit this kind of recursive internal Iinput/output. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m2 CHARACTER(20) :: ifile = 'abc def ghi jkl mno ' CHARACTER(3) :: char CONTAINS CHARACTER(3) FUNCTION foo() READ(ifile, *) char foo = 'abc' END FUNCTION END MODULE PROGRAM ex2 USE m2 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, char END PROGRAM Question 3: Fortran 2003 does not appear to prohibit modifying a character variable when it is being used as an internal file in a data transfer statement that is currently executing. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m3 CHARACTER(20) :: ifile = '' CONTAINS CHARACTER(3) FUNCTION foo() ifile = 'bad thing to do?' foo = 'abc' END FUNCTION END MODULE PROGRAM ex3 USE m3 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, flag END PROGRAM Question 4: Fortran 2003 does not appear to prohibit referencing a character variable when it is being used as an internal file in a data transfer statement that is currently executing. Was this program intended to be standard-conforming? If so, then what does the program print? MODULE m4 CHARACTER(20) :: ifile = '' LOGICAL :: flag = .FALSE. CONTAINS CHARACTER(3) FUNCTION foo() IF (ifile == ' xyz') THEN flag = .TRUE. END IF foo = 'abc' END FUNCTION END MODULE PROGRAM ex4 USE m4 WRITE(ifile, *) 'xyz', foo(), 'zyx' PRINT *, ifile PRINT *, flag END PROGRAM ANSWER: All of these examples were intended to be prohibited. Edits are provided to prohibit referencing or defining a variable used as an internal unit as a result of evaluating any output list items, or transferring values to any input list item. EDITS: In section 9.5.3.4, after the paragraph: "If an internal file has been specified, an input/output list item shall not be in the file or associated with the file." add these paragraphs [196:29+]: "During the execution of an output statement that specifies an internal file, no part of that internal file shall be referenced, defined, or become undefined as the result of evaluating any output list item. During the execution of an input statement that specifies an internal file, no part of that internal file shall be defined or become undefined as the result of transferring a value to any input list item." SUBMITTED BY: Rob James HISTORY: 05-141 m171 F03/0050 Submitted 06-368 m178 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0086 TITLE: Elemental and BIND(C) KEYWORDS: Elemental, BIND(C), ENTRY DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Is it allowed for a procedure to have both the BIND(C) and elemental attributes? Constraint C1242 disallows trivial ways of writing an elemental BIND(C) procedure. However, the following example achieves the effect for sub_c without violating the syntactic constraint. elemental subroutine sub(x) entry sub_c(x) bind(c) end subroutine sub ANSWER: No, it is not allowed. Constraint C1242 was intended to disallow the combination of elemental and BIND(C), but it inadvertently failed to cover the case shown in the above example. EDITS Replace C1242 in subclause 12.5.2.1 with [280:6-7] "C1242 An ELEMENTAL procedure shall not have the BIND attribute.". SUBMITTED BY: Richard Maine HISTORY: 07-101 m179 Submitted F03/0086 07-101 m179 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0088 TITLE: Defined operations/assignments and VOLATILE/ASYNCHRONOUS KEYWORDS: Defined operations, defined assignment, VOLATILE, ASYNCHRONOUS DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot PROBLEM: Fortran 2008 Unresolved Technical issue 097 asked a question that also affects Fortran 2003. Consider this example: INTERFACE ASSIGNMENT(=) SUBROUTINE s(a,b) REAL,INTENT(OUT),VOLATILE :: a(1,*) REAL,INTENT(IN) :: b(:) END SUBROUTINE END REAL,POINTER :: p(:,:),q(:) ... CALL s(p,q) ! Violation of constraint C1233 [271:9-11], ! associating P with A p = q ! No constraint violation because ! syntax is not being used QUESTION: Did Fortran 2003 intend to enforce constraints on in defined assignment? ANSWER: Yes, the constraints and restrictions should be enforced in defined assignment and in defined operator evaluation. Edits are provided below to do this. EDITS: [262:16] add at the end of the paragraph "All restrictions and constraints that apply to actual arguments in a reference to the function also apply to the corresponding operands in the expression as if they were used as actual arguments." [263:12] insert after "the second argument." "All restrictions and constraints that apply to actual arguments in a reference to the subroutine also apply to the left-hand-side and to the right-hand-side enclosed in parentheses as if they were used as actual arguments." SUBMITTED BY: Stan Whitlock HISTORY: 07-172 m179 Submitted F03/0088 {see 07-171 for F08 fix} 07-172 m179 Passed by J3 meeting 07-272 m181 Passed as changed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0089 TITLE: Interoperability of non-BIND derived types KEYWORDS: Interoperability, derived type DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot INTRODUCTION Subclause 15.2.3 of 04-007 says [398:9-12]: "A Fortran derived type is interoperable with a C struct type if the derived-type definition of the Fortran type specifies BIND(C) (4.5.1), the Fortran derived type and the C struct type have the same number of components, and the components of the Fortran derived type have types and type parameters that are interoperable with the types of the corresponding components of the struct type." QUESTIONS 1. Is a Fortran derived type for which BIND(C) is not specified interoperable with any C struct type? 2. Does a Fortran derived type interoperate with a C struct type that has a different number of components? 3. Does a Fortran derived type interoperate with a C struct type that specifies the same components in a different order? 4. Does a Fortran derived type with a pointer or allocatable component that has interoperable type and type parameters interoperate with any C struct type? ANSWERS: None of these Fortran derived types are interoperable with any C struct type. EDITS: [398:9] Replace "if" by "if and only if". SUBMITTED BY: Van Snyder HISTORY: 07-213 m180 Submitted F03/0089 07-213r2 m180 Passed by J3 meeting 07-272 m181 Passed by J3 letter ballot #13 ---------------------------------------------------------------------- NUMBER: F03/0092 TITLE: Procedure characteristics and unlimited polymorphic KEYWORDS: Procedure, unlimited polymorphic DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider abstract interface function foo (x) class(*) x class(*), pointer :: foo end function end interface procedure (foo), pointer :: proc_ptr procedure (foo), target :: proc_tgt proc_ptr => proc_tgt According to the rules of procedure pointer assignment at [144:39-41], proc_ptr and proc_tgt are required to have the same interface characteristics. However because an unlimited polymorphic entity is not considered to have a declared type, the rules for characteristics of dummy data objects [256:26-32] and characteristics of function results [257:2-8] are not applicable. In addition, rules at [145:5-6] require that proc_ptr and proc_tgt have the same function return type. This also does not apply to unlimited polymorphic data. Is the example intended to be standard-conforming? ANSWER: Yes, the example was intended to be standard-conforming. An edit is provided to clarify this. The characteristics however are adequately defined. FOO, and thus both PROC_PTR and PROC_TGT have no type, but are polymorphic; this precisely characterises an unlimited polymorphic entity. Only the requirement of type matching in 7.4.2.2 is incorrect. EDITS to 04-007: [145:5] After "the same type" insert " or both be unlimited polymorphic". SUBMITTED BY: Jim Xia HISTORY: 07-247 m181 F03/0092 Submitted 07-247r1 m181 Passed by J3 meeting 07-279/321 m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0093 TITLE: Allocatable array on intrinsic assignment with scalar expr KEYWORDS: allocatable array, intrinsic assignment DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider CHARACTER(:), ALLOCATABLE :: str(:) ALLOCATE (CHARACTER(1) :: str(0:9)) str = 'reallocate?' According to the third paragraph of 7.4.1.3, the variable STR should be deallocated on this assignment because it has a deferred length type parameter different from the ('reallocate?'); it should then be allocated with its length type parameter the same as that of the and with the shape and bounds of . But the STR cannot be allocated with the shape and bounds of the since it is a scalar. The standard, however, provides a possible interpretation for the shape of two paragraphs later where it says "If is a scalar and is an array, the is treated as if it were an array of the same shape as with every element of the array equal to the scalar value of ." Q(1). Should the variable STR be reallocated in this case? Q(2). If so, what are the values of its length type parameter, shape and bounds? ANSWER: (1) Yes, STR should be reallocated - that is the purpose of the combination of ALLOCATABLE and deferred type parameters. If the user does not wish for automatic reallocation he can use "str(:) = 'do not reallocate'" instead. (2) The length parameter of str after the assignment is 11 (the value returned by LEN('reallocate?')). The shape and bounds should be unchanged. An edit is provided to clarify this. Note that the standard does not forbid, but does not specify semantics for, str = 'oops' when STR is an unallocated array with a deferred length parameter. An edit is supplied to make it clear that this is not allowed. Note also that this applies to parameterized derived types with deferred type parameters. EDITS: [139:22-] Insert new sentence at beginning of paragraph "If is an unallocated allocatable array, shall be an array of the same rank as ." [139:25] Change "corresponding type parameters of ," to "corresponding type parameter of ." [139:25] Before ", with the shape of " Insert ". If is an array and is scalar it is allocated with the same bounds as before, otherwise it is allocated". SUBMITTED BY: Jim Xia HISTORY: 07-248 m181 F03/0093 Submitted 07-248r2 m181 Passed by J3 meeting 07-279/321 m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0094 TITLE: Final subroutine and VALUE attribute KEYWORDS: Final subroutine, VALUE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Currently, the F03 standard allows the VALUE attribute to be specified for the dummy argument of a final subroutine. This seems to defeat the purpose of final subroutine, which is intended to apply to the finalizable entity (the actual argument) itself. Should the dummy argument of a final subroutine be allowed to have the VALUE attribute? ANSWER: No, the VALUE attribute should not be allowed. An edit is provided to correct this oversight. EDITS to 04-007: [58:14] Replace "not be INTENT(OUT)" with "not have the INTENT(OUT) or VALUE attribute". SUBMITTED BY: Jim Xia HISTORY: 07-249 m181 F03/0094 Submitted 07-249r1 m181 Passed by J3 meeting 07-279/321 m182 Passed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0095 TITLE: Bounds remapped pointer assignment and ASSOCIATED KEYWORDS: pointer assignment, bounds-remapping, ASSOCIATED DEFECT TYPE: Interpretation STATUS: Passed by J3 letter ballot QUESTION: Case (v) of intrinsic inquiry function ASSOCIATED [305:5-9] says If TARGET is present and is an array target, the result is true if the target associated with POINTER and TARGET have the same shape, are neither of size zero nor arrays whose elements are zero-sized storage sequences, and occupy the same storage units in array element order. Otherwise, the result is false. If POINTER is disassociated, the result is false. This will cause the intrinsic to return false if the POINTER is pointer assigned to the TARGET with bounds-remapping (POINTER and TARGET can be of different ranks). The same issue also exists for case (vii). Is the POINTER associated with the TARGET if the POINTER is pointer assigned to the TARGET with bounds-remapping? ANSWER: No, it is not intended that ASSOCIATED(POINTER, TARGET) return true after pointer assignment using a bounds-remapping that changes the shape or rank. This was a conscious decision made in response to a Fortran 90 interpretation request concerning dummy arguments that are different shaped versions of the same array in the calling procedure. EDITS to 04-007: none SUBMITTED BY: Jim Xia HISTORY: 07-259 m181 F03/0095 Submitted 07-259r2 m181 Passed by J3 meeting 07-279/321 m182 Passed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0097 TITLE: Blanks as separators in NAMELIST input KEYWORDS: Namelist input, blanks, separators DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: 1) Was it intended that blanks be allowed as separators in Namelist Input? Consider a namelist input fragment: I = 3 J = 4 Page 243:12 says that the name-value subsequences are separated by value separators. Page 243:5 says that namelist value separators are the same as list directed value separators. Page 239:7 says those value separators are "...blanks between values" and then defines what the values are. The "J" above isn't a value, so the blanks aren't separators and the fragment is illegal for namelist input 2) Is there a similar problem with namelist comments as in this fragment? I = 3 ! this is a namelist comment Page 245:29-30 says that a name-value subsequence is separated from the ! in a comment by a value separator. ANSWER: 1) Yes, it was intended to allow blanks as separators for namelist input. Edits are supplied to correct the wording in the standard. 2) Yes, there is a similar problem with comments. The fragment is intended to be legal. The edits correct the error. EDITS: [243:5] Replace the paragraph by "A value separator for namelist formatting is a value separator for list-directed formatting (10.9), or one or more contiguous blanks between a nonblank value and the following object designator or "!" comment initiator." SUBMITTED BY: Dick Hendrickson HISTORY: 07-267 m181 F03/0097 Submitted 07-267r2 m181 Passed by J3 meeting 07-279/321 m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0098 TITLE: Does allocate with source= define subcomponents? KEYWORDS: allocate, source, define DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended that an allocate with a source= clause define subcomponents? Bullet 11 on 422 says "Successful execution of an ALLOCATE statement ...causes the subcomponent to become undefined." ANSWER: An Allocate with a SOURCE= specifier was intended to define subcomponents. In fact, none of the lists in clause 16 account for a SOURCE= specifier. Edits are supplied to clarify this. EDITS: [113:21] At the end of the last sentence in 6.3.1.1 insert "unless they are defined by a SOURCE= specifier" [421:27-28] 16.5.5, list item 19, modify by adding after "Allocation of an object", "except by an ALLOCATE statement with a SOURCE= specifier". [421:28+] 16.5.5, insert new list item after (19) "(19a) Successful execution of an ALLOCATE statement with a SOURCE= specifier causes a subobject of the allocated object to become defined if the corresponding subobject of the SOURCE= expression is defined." [422:41] 16.5.6, list item (11) insert "with no SOURCE= specifier" after "ALLOCATE statement" [422:43+] 16.5.6, add a new list item after (11), "(11a) Successful execution of an ALLOCATE statement with a SOURCE= specifier causes a subobject of the allocated object to become undefined if the corresponding subobject of the SOURCE= expression is undefined." SUBMITTED BY: Dick Hendrickson HISTORY: 07-268 m181 F03/0098 Submitted 07-268r2 m181 Passed by J3 meeting 07-279/321 m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0101 TITLE: Is UDDTIO output suitable for namelist and list-directed input KEYWORDS:UDDTIO, list-directed I/O, namelist I/O DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The first paragraph of 10.9.2 says that the form of the values produced by list-directed output is the same as that required for input. It also says values are separated blanks or commas, etc. The first paragraph of 10.10.2 has similar words for namelist output. It also requires that the variable name be produced in upper case and that the output consist of name-value pairs. Is it intended that output produced by user-defined derived type routines conform to these rules? ANSWER: No, it was not intended to constrain the user-derived type output values. There should be an exception similar to the one for adjacent undelimited character values. User derived type output fields do not need to be readable by either namelist or list-directed input. EDITS: [241:5] Add at the end of the paragraph "The form of the output produced by a user-defined derived type output routine invoked during list-directed output is specified by the invoked routine. It need not be compatible with list-directed input." [246:4] After "and logical values" add ", and output produced by user-defined derived type output" [246:7] Add at the end of the paragraph "The form of the output produced by a user-defined derived type output routine invoked during namelist output is specified by the invoked routine. It need not be compatible with namelist input." SUBMITTED BY: Dick Hendrickson HISTORY: 07-275 m181 F03/0101 Submitted 07-275r2 m181 Passed by J3 meeting 07-279/321 m182 Passed as changed by J3 letter ballot #14 ----------------------------------------------------------------------