J3/06-006T2 Interpretations for Fortran 2003 Corrigendum # 2 Completed Fortran 2003 Interpretations, May 10, 2006 Stan Whitlock for /interp > see 05-016 (05-006T1) for the closed F2003 interps in Technical > Corrigendum #2 (see draft N1659) [keep this text document to 70 characters per line]................... Table of Contents Part 0 contains the summary status of all of the Fortran interpretations Part 1 contains F2003 interpretations that are included in the F2003 Technical Corrigendum #2 ====================================================================== Part 0: Summary Status of these Fortran Interpretations ====================================================================== Note N: d == done {if S = C1 | C2 | T1 then done is assumed} * == active W == would go in F95 Corrigendum 3 if there were one Status S: Defect Type T: P == J3 consideration in progress C == Clarification M Passed by J3 meeting E Erratum B Passed by J3 letter ballot I Interpretation W Passed by WG5 ballot C1 Included in F95 corrigendum 1 (see N1422) C2 Included in F95 corrigendum 2 (see N1473) T1 Included in F03 corrigendum 1 (see N1636/N1640) X Excluded for the reasons given N S T number title - - - ------ ----- W E F03/0008 Pointer assignment and arrays W E F03/0012 Procedure pointers and the EXTERNAL attribute W E F03/0020 Kinds of intrinsic type parameters W E F03/0023 IEEE_SET/GET_UNDERFLOW_MODE W E F03/0025 Abstract types in CLASS IS type guard statements W E F03/0026 Intrinsic types in CLASS IS type guard statements W E F03/0027 Assumed character length in type guard statements W E F03/0028 Commas in complex namelist output W E F03/0029 Negative zero and intrinsic functions W E F03/0045 Finalization and assumed-sized arguments with INTENT(OUT) W I F03/0056 Null input values and list-directed UDDTIO W E F03/0057 Namelist I/O and UDDTIO W I F03/0058 Recursive namelist output W E F03/0060 Default initialization of INTENT(OUT), assumed-size arrays {subsumed by F03/0045} W E F03/0061 Polymorphism and explicit-shape or assumed-size dummy arguments W E F03/0062 Finalization of array constructors W I F03/0066 Precision of operation W I F03/0067 Accuracy of conversion of real literal constants W E F03/0068 First character of namelist output records W E F03/0069 Procedure pointers in defined assignment W E F03/0070 Can child I/O statements be advancing I/O statements? W E F03/0072 Default initialization for "automatic" components ====================================================================== Part 1: Fortran 2003 Interpretation Requests ====================================================================== NUMBER: F03/0008 TITLE: Pointer assignment and arrays KEYWORDS: pointer assignment, array, data-ref DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: There appears to be no explicit requirement that the s in R736 and R741 be scalar. If data-pointer-object and proc-component ref were data-refs, then C614 would prohibit the s from being arrays. However, although the syntax looks like a special case of a data-ref, nothing appears to say that R736 and R741 actually constitute data-refs. The standard gives no interpretation as to what the meaning would be in the case of an array. Even when variable is a scalar, the standard does not appear to define what the properties (such as type and shape) of a data-pointer-object or proc-pointer-object are in the case where the syntax has a "%". All we have is a syntax with no established meaning. Q1. Is the in R736 or R741 allowed to be an array? Q2. Is the interpretation of the forms in R736 and R741 the same as that of a data-ref? ANSWER: A1. No. The standard provides no interpretation of what such a form would mean. Therefore, by the first sentence of 1.5, it is not standard-conforming. Edits are provided to make this prohibition more direct. A2. Yes. EDITS: All edits refer to 04-007. [143:12,24,35,37] Insert "" before "", four times. SUBMITTED BY: Richard Maine HISTORY: 04-333 m169 F03/0008 Submitted 04-333r1 m169 Passed by J3 meeting 04-418r1 m170 Failed J3 letter ballot #9 04-421 m170 Revised - Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0012 TITLE: Procedure pointers and the EXTERNAL attribute KEYWORDS: Procedure pointers, EXTERNAL DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is the following program unit standard conforming? SUBROUTINE SUB ( RPP ) REAL, EXTERNAL, POINTER :: RPP EXTERNAL :: PP POINTER :: PP PROCEDURE(REAL), POINTER :: PPP => NULL() END SUBROUTINE SUB The last sentence of "5.1.2.6 EXTERNAL attribute" appears to indicate that it is allowed: "A procedure that has both the EXTERNAL and POINTER attributes is a procedure pointer." That the title of subclause 12.2.1.2 is "Characteristics of dummy procedures and dummy procedure pointers" suggests that it is allowed. That subclause continues "... whether it is a pointer, ..." so it was clearly envisioned that at least dummy procedures could have the POINTER attribute. C1216 [264:30] appears to require PPP to be allowed: "C1216 (R1214) If => appears in , the procedure entity shall have the pointer attribute." On the other hand, A conspiracy of C512 [72:28-29] "C512 (R501) If the POINTER attribute is specified, the ALLOCATABLE, TARGET, EXTERNAL, or INTRINSIC attribute shall not be specified." the second sentence of subclause 5.1.2.6 [80:38-40] "This [EXTERNAL] attribute may also be specified by ... a ..." the first paragraph of subclause 5.2 [85:15ff] "The combination of attributes that may be specified for a particular entity is subject to the same restrictions ... regardless of the method of specification. This also applies to the PROCEDURE, EXTERNAL and INTRINSIC statements." and the last sentence of the first paragraph of 12.3.2.3 [264:8] "It [the procedure declaration statement] specifies the EXTERNAL attribute...." appears to completely wipe out procedure pointers (PPP because of the first paragraph of 12.3.2.3). C521 [73:6-7] and C568 [91:5] also appear to prohibit RPP and PP: "C521 (R504) The shall be the name of an external function, a function dummy procedure{, or a statement function}." "C568 (R541) A shall also be declared in a ." But then the first paragraph after R1210 (defining the EXTERNAL statement) [264:1] appears to allow RPP and PP: "Each shall be the name of ... a procedure pointer...." There is also a problem with protected procedure pointers. C535 clearly envisions their existence: "C535 (R501) The PROTECTED attribute is permitted only for a procedure pointer...." while C536 prohibits their existence: "C536 (R501) If the PROTECTED attribute is specified, the EXTERNAL ... attribute shall not be specified." ANSWER: The discussion of procedure pointers is indeed inconsistent. The program unit is intended to be standard conforming. It was an oversight during the development of the procedure pointer facility that the EXTERNAL attribute was not removed from C512, that "procedure pointer" was not added to C521, that C535 and C536 contradict one another, and that an external statement and specifying the EXTERNAL attribute in a type declaration statement were not allowed in C568. It is not helpful that the last sentence of the first paragraph of subclause 5.2 refers to "PROCEDURE ... statements" (which could be confused with the PROCEDURE statement in an interface block) where it should refer to "procedure declaration ... statements." EDITS: Delete ", EXTERNAL" from C512 [72:28]. Insert ", a procedure pointer" after "dummy procedure" in C521 [73:7]. Replace C536 [73:35-36]: "C536 (R501) If the PROTECTED attribute is specified, the INTRINSIC or PARAMETER attribute shall not be specified. If the PROTECTED and EXTERNAL attributes are specified, the POINTER attribute shall also be specified." Replace the last sentence of the first paragraph of subclause 5.2 [86:1] by "This also applies to procedure declaration statements, and to EXTERNAL and INTRINSIC statements." Replace C568 [91:5]: "C568 (R541) The EXTERNAL attribute (5.1.2.6) shall be explicitly specified for a ." SUBMITTED BY: Van Snyder HISTORY: 04-358 m169 F03/0012 Submitted 04-358r2 m169 Revised 04-418r1 m170 Failed J3 letter ballot #9 04-401r2 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 - fix typo ---------------------------------------------------------------------- NUMBER: F03/0020 TITLE: Kinds of intrinsic type parameters KEYWORDS: type parameter, kind, intrinsic type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Q1. What are the kinds of the type parameters for intrinsic types? In most contexts, it doesn't matter. Fortran 95 did not even have the concept of the kind of a type parameter or a context in which such a thing could be detected in a standard-conforming program. Fortran 2003 added the concept in support of derived types. It also added a syntax which exposes the question for intrinsic types. Q2. What is the KIND of a type parameter inquiry? Q3. For example, consider the program program what_kind character c write (*,*) kind(c%kind) == kind(0) write (*,*) kind(c%len) == kind(0) end Are both write statements guaranteed to print .true. (meaning that the c%kind and c%len are of default kind) or not? For KIND parameters, although I can't find it explicitly stated, I see fairly strong evidence that all intrinsic kind parameters are intended to be default integers. This evidence is in the intrinsic functions. The KIND intrinsic function and all the selected_*_kind functions are specified to return default integers, which would make for some strangeness if the kind parameters were not default integer, in particular if the KIND intrinsic could not return the kind of its argument because that kind could not be represented in a default integer. There also seems no obvious benefit to having the kind of the intrinsic kind parameters be anything other than default. In practice, the number of supported values for kind is small and would have no trouble being represented in a default integer; large arrays of kind values are rare, so there isn't much benefit in using representations smaller than default. For character length, I see no similar evidence. Indeed, the LEN intrinsic seems to suggest that lengths might be other than default integer. I believe that there was clear intent to facilitate (but not require) support for character lengths longer than could be expressed by a default integer. In most contexts, it doesn't directly matter what the kind of length is. Parameter specifications in type-specs don't have to match in kind. So the user could specify and do arithmetic on lengths using whatever kind was appropriate for the anticipated problem sizes. The limit on maximum character length is processor-dependent anyway and is not necessarily the same as HUGE(whatever) (though it is a bit hard to imagine how it could usefully be larger). The only context in which I can see that might matter is in a type parameter inquiry (6.1.3). We don't appear to have defined the kind of a type parameter inquiry. Although we didn't say, I am assuming that a type parameter inquiry ought to "return" the kind of the type parameter it is inquiring about. Otherwise, there would be no way to inquire about the type parameter values of some derived type variables (if the values didn't fit in a default integer). We probably ought to explicitly say, though. ANSWER: Q1. The kind parameters of all the intrinsic types are of default integer kind. The kind parameter of the intrinsic character length parameter is processor-dependent. The support for this answer is as described in the question. Edits are provided to make this answer explicit. Q2. The kind parameter of a type inquiry is the same as that of the type parameter inquired about. See page 123, lines 35-36. Q3. The first write statement is guaranteed to print a .true. value; it is processor dependent whether the second one prints a .true. or .false. value. EDITS: All edits apply to 04-007. At [36:14], [37:30], [39:15], [40:14], and [44:2], insert the following sentence before "The kind": The kind type parameter is of type default integer. At [40:10], before "its", insert "its kind is processor-dependent and". SUBMITTED BY: Richard Maine HISTORY: 04-408 m170 F03/0020 Submitted 04-408r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0023 TITLE: IEEE_SET/GET_UNDERFLOW_MODE KEYWORDS: IEEE, underflow mode DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is it allowed for the argument of IEEE_SET_UNDERFLOW_MODE or IEEE_GET_UNDERFLOW_MODE to be an array? There appears to be no restriction against arrays in these procedures. For IEEE_SET_UNDERFLOW_MODE, it is ill-defined what an array would mean. The wording implies a scalar, in that it talks about being true or false, but the restriction to scalars is not explicit. For IEEE_GET_UNDERFLOW_MODE, it could be defined, but seems a little silly and nonparallel. The similar procedures for rounding mode do explicitly specify that their arguments are scalar. ANSWER: No, arrays are not allowed for these arguments. Edits are provided to correct this error. EDITS: [374:21] Add "scalar and" after "shall be" [380:13] Add "scalar and" after "shall be" SUBMITTED BY: Richard Maine HISTORY: 04-420 m170 F03/0023 Submitted - Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0025 TITLE: Abstract types in CLASS IS type guard statements KEYWORDS: ABSTRACT, CLASS IS, type guard, SELECT TYPE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: PROGRAM foo TYPE, ABSTRACT :: base INTEGER i END TYPE TYPE, EXTENDS(base) :: child INTEGER j END TYPE CLASS(*), POINTER :: x TYPE(child), TARGET :: c1 x => c1 SELECT TYPE (x) CLASS IS (base) PRINT *, 'Class is base' CLASS DEFAULT PRINT *, 'Class is not base' END SELECT END Constraint C401 seems to prohibit the abstract type "base" from appearing in a CLASS IS type guard statement, thus prohibiting this program. There seems to be no reason to prohibit this, and allowing it seems to be useful in some situations. Was this program intended to be standard-conforming? ANSWER: Yes, this program was intended to be standard-conforming. Edits are provided to correct this oversight. EDITS: All edits refer to 04-007. [162:17] Change "" to "". [162:19] After "", insert "or ". [162:20] After "", insert "or ". [162:21] After "", insert "or ". SUBMITTED BY: Rob James HISTORY: 04-411 m170 F03/0025 Submitted 04-411r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0026 TITLE: Intrinsic types in CLASS IS type guard statements KEYWORDS: CLASS IS, type guard, SELECT TYPE, intrinsic type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: PROGRAM foo CLASS(*), POINTER :: x INTEGER, TARGET :: i x => i SELECT TYPE (x) CLASS IS (INTEGER) PRINT *, 'How can INTEGER be a class?' END SELECT END The description of a CLASS IS type guard statement refers to an extension of the type specified. This makes no sense for nonextensible types. C815 disallows all nonextensible derived types, but nothing disallows intrinsic types, which are also nonextensible. Was this program intended to be standard-conforming? ANSWER: No, this program was not intended to be standard-conforming. Edits are supplied to correct this oversight. EDITS: All edits refer to 04-007. Note that these edits are the same as the edits proposed for F03/0025. [162:17] Change "" to "". [162:19] After "", insert "or ". [162:20] After "", insert "or ". [162:21] After "", insert "or ". SUBMITTED BY: Rob James HISTORY: 04-412 m170 F03/0026 Submitted 04-412r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0027 TITLE: Assumed character length in type guard statements KEYWORDS: CHARACTER, assumed length, type guard, SELECT TYPE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: PROGRAM foo CHARACTER, TARGET :: c CLASS(*), POINTER :: p p => c SELECT TYPE (p) TYPE IS (CHARACTER(*)) PRINT *, 'Character of length ', LEN(p) END SELECT END Constraint C814 says that, in a type guard statement, the shall specify that each length type parameter is assumed. Constraint C416 does not list a type guard statement as a context in which "*" can be used as a length type parameter for a character. Was this program intended to be standard-conforming? ANSWER: Yes, this program was intended to be standard-conforming. Edits are supplied to correct this oversight. EDITS: All edits refer to 04-007. These edits assume that the edits for F03/0026 are passed. [41:9] Remove "or". [41:9+] Add a new list item: "(3.5) in the or of a type guard statement (8.1.5), or" [41:33+] Add a new list item: "(3.5) If used in the or of a type guard statement, the associating entity assumes its length from the selector." SUBMITTED BY: Rob James HISTORY: 04-413 m170 F03/0027 Submitted 04-413r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 - fix edits ---------------------------------------------------------------------- NUMBER: F03/0028 TITLE: Commas in complex namelist output KEYWORDS: Namelist, complex formatting, comma, semicolon DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The 7th paragraph in 10.9.2 for list directed output says: "Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, each produced as defined above for real constants. The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal edit mode is COMMA." There are similar words in most other places where complex formatting is described. The second paragraph of 10.10.1.3 Namelist group object list items says: "When the next effective item is of type complex, the input form of the input value consists of a left parenthesis followed by an ordered pair of numeric input fields separated by a comma and followed by a right parenthesis. " Other places correctly describe namelist complex output as having a separator, either a comma or a semicolon, depending on the decimal edit mode. Should the namelist version be reworded to say "comma or semicolon"? ANSWER: Yes. Edits are supplied to correct this oversight. In addition, a similar issue exists for list directed input of undelimited character values and namelist output of character values. EDITS: All edits refer to 04-007. [240:13] Replace "comma" with "comma (if the decimal edit mode is POINT), semicolon (if the decimal edit mode is COMMA)" [244:29] Replace "comma" with "separator". [244:30] Before "The first", add the following sentence: The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal edit mode is COMMA. [244:32] Replace "comma" with "separator". [244:33] Replace "comma" with "separator". [245:4] after "comma," insert " semicolon," SUBMITTED BY: Dick Hendrickson HISTORY: 04-409 m170 F03/0028 Submitted 04-409r1 m170 Passed by J3 meeting 05-146 m171 Failed interp letter ballot #10 05-164 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 05-257 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0029 TITLE: Negative zero and intrinsic functions KEYWORDS: Negative zero, IEEE, intrinsic functions DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: 4.4.2 states "Processors that distinguish between positive and negative zeros shall treat them as equivalent ... as actual arguments to intrinsic procedures other than those for which it is explicitly specified that negative zero is distinguished" Q1. Does this mean that TRANSFER(-0.0,42) is required to give the same answer as TRANSFER(+0.0,42)? The definition of TRANSFER has no explicit mention of negative zero. Q2. Does this mean that MERGE(+0.0,-0.0,flag) always returns +0.0? Q3. Does this mean that SPREAD(-0.0,2) has the value [+0.0,+0.0] instead of [-0.0,-0.0]? Q4. Does this mean that RESHAPE([-0.0],[1]) has the value [+0.0] instead of [-0.0]? Q5. Does this mean that SET_EXPONENT(-0.0,10) is +0.0 not -0.0? Q6. Does this mean that if a REAL variable X has a negative zero value, REAL(x,...) has a positive zero value? Q7. Does this mean that CMPLX(0,-0.0) has the value (+0.0,+0.0) instead of (+0.0,-0.0)? Q8. Does this mean that if a complex variable C has a negative zero imaginary part, that AIMAG(C) returns +0.0 instead of -0.0? Q9. In any other intrinsic function, if the definition of the intrinsic would imply a different result for negative zero than for positive zero, does this mean that the function returns the positive zero answer for a negative zero argument? ANSWER: Q1. No. The definition of TRANSFER explicitly states that its result has the same physical representation as its first argument. This would not be possible if "equivalent" meant that the exact same result had to be produced. Q2. No, this would contradict the definition of MERGE. Q3. No. SPREAD "replicates" its argument, which means that the value of each copy is the same as the original, not just compare equal. As with TRANSFER, this would not be possible with the suggested interpretation of the text in 4.4.2. Q4+. No. As with the previous questions, this would require an overly strict interpretation of the term "equivalent", contradicting the clear intent of the function in question. DISCUSSION: The term "equivalent" in the quoted text in 4.4.2 refers to the concept of mathematical equivalence, not physical or computational equivalence. A clarifying edit is supplied. EDITS: [38:2] Before "equivalent" insert "mathematically". SUBMITTED BY: Malcolm Cohen HISTORY: 04-422 m170 F03/0029 Submitted - Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0045 TITLE: Finalization and assumed-size arguments with INTENT(OUT) KEYWORDS: finalization, INTENT(OUT), assumed size, dummy argument DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i CONTAINS FINAL :: finalizeT END TYPE CONTAINS ELEMENTAL SUBROUTINE finalizeT(f) TYPE(t), INTENT(INOUT) :: f f%i = 10 END SUBROUTINE END MODULE SUBROUTINE xyz (d) USE m TYPE(t), INTENT(OUT) :: d(*) END SUBROUTINE PROGRAM foo USE m EXTERNAL xyz TYPE(t) :: a(10) = t(5) CALL xyz(a(2)) END PROGRAM 4.5.5.2 of Fortran 2003 states: When a procedure is invoked, a nonpointer, nonallocatable object that is an actual argument associated with an INTENT(OUT) dummy argument is finalized. For assumed-size arguments, this situation is similar to that of default initialization with INTENT(OUT). Default initialization is prohibited for INTENT(OUT), assumed-size dummy arguments by C544. A similar restriction on finalization may have been overlooked. Was this program intended to be standard-conforming? ANSWER: No, this program was not intended to be standard-conforming. An edit is supplied to correct this oversight. DISCUSSION: The unstated philosophy of assumed-size arrays in the standard is that no action is allowed on an assumed-size array which would need to be applied elementally to the whole array. That is why no whole array assignment is allowed, for example. In accordance with this philosophy, (1) types with ultimate allocatable components also need to be excluded from being INTENT(OUT) assumed-size, as procedure invocation in this case requires deallocation of all the allocated components. (2) polymorphic INTENT(OUT) assumed-size arrays should also be excluded, as they might have finalisation, default initialisation or allocatable components. This interp subsumes Fortran 2003 interp #0060. EDITS: All edits refer to 04-007. [80:9] Before "of a type", insert "polymorphic, of a finalizable type, of a type with an ultimate allocatable component, or". SUBMITTED BY: Rob James HISTORY: 05-136 m171 F03/0045 Submitted, passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 05-256 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0056 TITLE: Null input values and list-directed UDDTIO KEYWORDS: null value, UDDTIO DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m PRIVATE TYPE, PUBLIC :: t INTEGER i INTEGER j CONTAINS PROCEDURE, PRIVATE :: readFormatted => readFormattedT GENERIC :: READ(FORMATTED) => readFormatted END TYPE CONTAINS SUBROUTINE readformattedT(dtv, unit, iotype, v_list, iostat, iomsg) CLASS(t), INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(*), INTENT(INOUT) :: iomsg READ (unit, *) dtv%i READ (unit, *) dtv%j END SUBROUTINE END MODULE PROGRAM p USE m INTEGER i TYPE(t) x, y, z x%i = 10 x%j = 15 y%i = 20 y%j = 25 z%i = 30 z%j = 35 i = 100 READ (*,*) x, y, z, i PRINT *, x, y, z, i END PROGRAM The following is given as input to this program: 1044 2167 3977 / 1 2 3 10.9.1.1 of Fortran 2003 (Null values) states: A slash encountered as a value separator during execution of a list-directed input statement causes termination of execution of that input statement after the assignment of the previous value. If a child data transfer statement encounters a slash as a value separator, it is unclear whether this statement applies to just the child statement, or to the parent data transfer statement as well. The significance for any subsequent child statement is also unclear. What is the behaviour of this program when it is given the specified input? ANSWER: When a child data transfer statement encounters a slash as a value separator, only that data transfer statement encounters the slash. None of its parent data transfer statements encounters the slash. Only the data transfer statement that encounters the slash is terminated. The program above should print the following: 1044.2167.3977.25.1.2.3 where "." represents a value separator. EDITS: None. SUBMITTED BY: Rob James HISTORY: 05-171 m172 F03/0056 Submitted 05-218 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0057 TITLE: Namelist I/O and UDDTIO KEYWORDS: namelist, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Can namelist I/O ever invoke a user-defined derived-type I/O procedure? 10.10.1.2 of Fortran 2003 (Namelist input values) implies that namelist input cannot invoke a user-defined derived-type I/O procedure. It says that, for a derived-type variable, "the effect is as if the variable represented were expanded into a sequence of scalar list items of intrinsic data types", which would preclude any derived-type I/O. However, the same sentence says that this is done "in the same way that formatted input/output list items are expanded (9.5.2)", which would result in some effective list items of derived type. 9.5.3.6 and 9.5.3.7.2 also imply that a user-defined derived-type I/O procedure could be invoked for a namelist group object. ANSWER: Yes, namelist I/O can invoke a user-defined derived-type I/O procedure. Edits are provided to correct this problem. EDITS: All edits refer to 04-007. [244:8] Remove "of intrinsic data types". [244:10] Remove "intrinsic". SUBMITTED BY: Rob James HISTORY: 05-172 m172 F03/0057 Submitted 05-219 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0058 TITLE: Recursive namelist output KEYWORDS: UDDTIO, namelist, output DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE mod PRIVATE TYPE, PUBLIC :: node INTEGER :: value = 0 CONTAINS PROCEDURE, PRIVATE :: nodeFormattedWrite => writeroutine GENERIC :: WRITE(FORMATTED) => nodeFormattedWrite END TYPE CONTAINS SUBROUTINE writeroutine(dtv, unit, iotype, vlist, iostat, iomsg) CLASS(node), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=*), INTENT(INOUT) :: iomsg REAL a NAMELIST /inner/ a a = 4.0 WRITE(unit, NML=inner) END SUBROUTINE END MODULE PROGRAM foo USE mod TYPE(node) :: a(2) NAMELIST /outer/ a a(1)%value = 1 a(2)%value = 2 WRITE(*, NML=outer) END PROGRAM Is the following output standard-conforming for the above program? If not, please give an example of standard-conforming output. &OUTER A= &INNER A=4.000000000 /, &INNER A=4.000000000 / / ANSWER: Yes EDITS: None SUBMITTED BY: Rob James HISTORY: 05-173 m172 F03/0058 Submitted 05-220 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0060 TITLE: Default initialization of INTENT(OUT), assumed-size arrays KEYWORDS: default initialization, INTENT(OUT), assumed size, polymorphism DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE base INTEGER I END TYPE TYPE, EXTENDS(base) :: child INTEGER :: j = 5 END TYPE CONTAINS SUBROUTINE sub(b) CLASS(base), INTENT(OUT) :: b(*) END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(child) :: c(3) c%i = 12 c%j = 47 CALL sub(c) PRINT *, c%j END PROGRAM C544 prevents nonpolymorphic, INTENT(OUT), assumed-size arrays from having default initialization. The polymorphic case, however, is not checkable at compile time, so it cannot be a constraint. Was it intended that the dynamic type of an INTENT(OUT), assumed-size array could have default initialization? If so, what does the above program print? ANSWER: No, this was not intended. This interp is subsumed by Fortran 2003 interp # 45, which contains edits making the above example non-conforming. EDITS: None SUBMITTED BY: Rob James HISTORY: 05-175 m172 F03/0060 Submitted 05-222 m173 Edit provided 05-222r1 m173 Subsumed by 0045 - Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0061 TITLE: Polymorphism and explicit-shape or assumed-size dummy arguments KEYWORDS: polymorphism, assumed size, actual argument, dummy argument DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE t1 INTEGER :: i END TYPE CONTAINS SUBROUTINE abc (b) CLASS(t1) :: b(*) EXTERNAL xyz CALL xyz(b(2)) END SUBROUTINE END MODULE SUBROUTINE xyz(d) USE m TYPE(t1) :: d(2,3) END SUBROUTINE PROGRAM foo USE m TYPE, EXTENDS(t1) :: t2 INTEGER :: j END TYPE TYPE(t2) a(10) CALL abc(a(2)) END PROGRAM During the execution of "xyz", the dummy argument "d" is sequence associated with the associated actual argument (which is true if "d" has either explicit shape or assumed size). This implies that the entity that is argument associated with "d" must be contiguous. The dummy argument "b" of the module subroutine "abc" is polymorphic, and its dynamic type in this case is different than its declared type. In this scoping unit, "xyz" has an implicit interface, so we know it doesn't have any polymorphic arguments. So, the dummy argument of "xyz" must be nonpolymorphic, and have the same declared type as the actual argument (b(2)). This implies that we only want to pass the parent portion of b(2). But the dummy argument of "xyz" may be an explicit-shape or assumed-size array (in this case, it is an explicit-shape array). This means that we have to pass a contiguous array to "xyz". This wouldn't be a problem if the dynamic type of "b" was the same as the declared type, but in this case it is not. The parent portion of "b" (from element 2 to the end of the array) must be copied into a temporary array. The compiler cannot possibly know how big "b" is because it is an assumed-size array, so it is impossible to make such a copy. Was this program intended to be standard-conforming? ANSWER: No, this program was not intended to be standard-conforming. Edits are provided to correct this oversight. EDITS: All edits refer to 04-007. [270:27] Change "assumed-shape or pointer" to "assumed-shape, pointer, or polymorphic". SUBMITTED BY: Rob James HISTORY: 05-176 m172 F03/0061 Submitted 05-223 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0062 TITLE: Finalization of array constructors KEYWORDS: Finalization, array constructor DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER i CONTAINS FINAL :: finalizeT END TYPE CONTAINS SUBROUTINE finalizeT(obj) TYPE(t) :: obj(:) PRINT *, 'Finalizing a rank-1 array of type t' END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: a a%i = 5 PRINT *, (/ (a, i=1,5) /) END PROGRAM If the PRINT statement in the main program was printing a function result or a structure constructor, rather than an array constructor, it is clear that the object should be finalized after that PRINT statement. However, for array constructors, this does not appear to be the case. In the main program above, should the entity created by the array constructor be finalized after execution of the PRINT statement? ANSWER: Yes, the array constructor should be finalized. Edits are provided to correct this oversight. EDITS: This edit refers to 04-007. [59:27] Replace both occurrences of "structure" with "structure or array". This edit refers to the edit introduced by interpretation F03/0007. Replace the first occurrence of "structure" with "structure or array". SUBMITTED BY: Rob James HISTORY: 05-177 m172 F03/0062 Submitted 05-224 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0066 TITLE: Precision of operation KEYWORDS: precision, operation DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Given REAL X X = ... some value ... IF( (X+3.0) .EQ. 3.0 )... may the X+3.0 be computed with more range and/or precision than that of REAL? In other words, is PRECISION(X) .EQ. PRECISION(X+3.0) always true; or is PRECISION(X) .LT. PRECISION(X+3.0) sometimes true? References are to J3/04-007. 2.4.1.1 Intrinsic type has "The kind type parameter indicates ... the decimal precision and exponent range for the real and complex types, ..." 7.1.4.2 Type, type parameters, and shape of the result of an operation has in (4) "For an expression x1 op x2 where op is a numeric intrinsic binary operator with both operands of the same type and kind type parameters, ..., the kind type parameter of the expression is identical to that of each operand." Since X and 3.0 are the same type and have the same kind type parameters, 7.1.4.2 (4) appears to require the X+3.0 have just the range and precision of REAL; no more, no less (otherwise, the precision is not identical). But, several members of the J3 email list have said that the "+" may be done with more precision; using either 1.4(6) or 7.1.8.3 as the reason. Perhaps something alone the lines of "The values of floating operands and of the results of floating expressions may be represented in greater precision and range than that required by the kind type parameter; the kind type parameter is not changed thereby." should be added to 7.1.4.2(4). QUESTION: Is PRECISION(X) .EQ. PRECISION(X+3.0) always true? ANSWER: Yes, that is the definition of PRECISION. The PRECISION intrinsic has nothing to do with the precision in which the computation X+3.0 is computed. 7.1.4.2 (4) only describes the precision of the end result of the computation. The weasel words in 1.4 (6) allow the processor to compute this expression in higher precision than REAL. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-193 m173 F03/0066 Submitted 05-193r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0067 TITLE: Accuracy of conversion of real literal constants KEYWORDS: conversion, accuracy DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: The following is independent of IEEE-754. Fortran 2003 10.6.1.2.6 covers conversions between "decimal values" and "internal values" and has some strong requirements. Are there equivalent requirements on accuracy for conversions of real literal constants? Sections 4.1.2 and 4.4.2 seems like the places to find them (if they exist). What rounding mode is used for conversions of real literal constants? Is the same rounding mode used for all such conversions? The following four questions are about positive values, but the same would apply to negative values. Must all "decimal values" in the range smallest non-zero finite internal value (which could be a denormal) to largest finite internal value, e.g. 0.1, be converted? Must all "decimal values" in the range zero to smallest non-zero finite internal value, e.g. 1.0e-999999999, be converted? Must all "decimal values" larger than the largest finite internal value, e.g. 9.9e+99999999999, be converted if infinity is an internal value? What does nearest rounding mean for these cases? What requirements exist for "decimal values" larger than the largest finite internal value if infinity is not an internal value? ANSWER: There are no requirements on accuracy for conversions of real literal constants. The standard does not specify the rounding mode used for conversions of real literal constants, nor does it require the same rounding mode to be used for all conversions. Whether all decimal values in any range can be converted is not standardized. There are no requirements for "decimal values" larger than the largest finite internal value whether infinity is an internal value or not. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-206 m173 F03/0067 Submitted 05-206r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0068 TITLE: First character of namelist output records KEYWORDS: namelist, output, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The last sentence of 10.10.2.2 of Fortran 2003 states: Except for continuation of delimited character sequences, each output record begins with a blank character. If a namelist output statement causes a user-defined derived-type output procedure to be called, was it intended to be standard- conforming for that procedure to create a new record (perhaps by using the slash edit descriptor) that does not begin with a blank character? ANSWER: Yes, this situation was intended to be standard-conforming. Explicit formatting in user-defined derived-type output is not required to output a leading blank in this case. An edit is provided to correct this oversight. EDITS: All edits refer to 04-007. [247:33] Before "continuation", insert "new records created by explicit formatting within a user-defined derived-type output procedure or by". SUBMITTED BY: Rob James HISTORY: 05-227 m173 F03/0068 Submitted 05-227r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0069 TITLE: Procedure pointers in defined assignment KEYWORDS: procedure pointer, defined assignment DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: In 12.3.2.1.1 of Fortran 2003, at [262:8-9], the following is stated about the dummy arguments of a function that defines an operation: The dummy arguments shall be nonoptional dummy data objects and shall be specified with INTENT (IN). This clearly states that a dummy argument of such a function cannot be a procedure pointer. The same is not stated for the dummy arguments of a subroutine that defines assignment. Was it intended that procedure pointers should be allowed in defined assignment, but not in defined operations? ANSWER: No. It was not intended that procedure pointers should be allowed in either defined assignment or defined operations. An edit is provided to correct this oversight. EDITS: All edits refer to 04-007. [263:6] Replace "Each argument shall be nonoptional." with "The dummy arguments shall be nonoptional dummy data objects." SUBMITTED BY: Rob James HISTORY: 05-228 m173 F03/0069 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 ---------------------------------------------------------------------- NUMBER: F03/0070 TITLE: Can child I/O statements be advancing I/O statements? KEYWORDS: UDDTIO, ADVANCE= DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot [175:30-31] of Fortran 2003 states: An advancing input/output statement always positions a record file after the last record read or written, unless there is an error condition. Since a child I/O statement does not position a file after the last Record [194:19][199:8-9], this implies that a child I/O statement cannot be an advancing I/O statement. [189:6-9] of Fortran 2003 states: The ADVANCE= specifier determines whether advancing input/output occurs for this input/output statement. If YES is specified, advancing input/output occurs. If NO is specified, nonadvancing input/output occurs (9.2.3.1). If this specifier is omitted from an input/output statement that allows the specifier, the default value is YES. This clearly states that any data transfer statement is an advancing I/O statement if the value 'NO' is not specified for the ADVANCE= specifier. These two statements seem to contradict each other. QUESTION: If a child I/O statement does not have an ADVANCE= specifier with the value 'NO', is it an advancing I/O statement? DISCUSSION: The answer to this question affects the value for the IOSTAT variable for child READ statements in some situations. For example, in the following program, the value of "stat1" should be equal to IOSTAT_EOF if the child READ statement is advancing, but it should be equal to IOSTAT_EOR if the statement is nonadvancing. MODULE m TYPE t CHARACTER(2) :: x(2) CONTAINS PROCEDURE :: readT GENERIC :: READ(FORMATTED) => readT END TYPE CONTAINS SUBROUTINE readT(dtv, unit, iotype, v_list, iostat, iomsg) CLASS(t), INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(*), INTENT(INOUT) :: iomsg READ (unit, '(2a2)', IOSTAT=iostat) dtv%x END SUBROUTINE END MODULE PROGRAM p USE m USE, INTRINSIC :: ISO_FORTRAN_ENV TYPE(t) t1 CHARACTER(3) :: c = '123' INTEGER stat1 READ (c, *, IOSTAT=stat1) t1 PRINT *, (stat1 == IOSTAT_EOR), (stat1 == IOSTAT_EOF) END PROGRAM ANSWER: No, such a child I/O statement is not advancing. Edits are provided to correct this inconsistency. EDITS: All edits refer to 04-007. [189:7] After "this" insert " nonchild". [189:9] Replace "from an" with "from a nonchild". [189:9] After "YES." Insert " A child input/output statement is a nonadvancing input/output statement, and any ADVANCE= specifier is ignored." [199:8+] Add a new bullet: " o Any ADVANCE= specifier in a child input/output statement is ignored." SUBMITTED BY: Rob James HISTORY: 05-229 m173 F03/0070 Submitted 05-229r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 - typos fixed N1658 m176 Passed WG5 ballot N1657 - fix edits ---------------------------------------------------------------------- NUMBER: F03/0072 TITLE: Default initialization for "automatic" components KEYWORDS: Parameterized Derived Type, Default Initialization DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider TYPE t(len) INTEGER,LEN :: len CHARACTER(len) :: cvalue = "xyz" END TYPE SUBROUTINE s(n) TYPE(t(n)) x ... TYPE t2(len2) TYPE(t(len2)) :: tvalue = t(10,"fred nurke") END TYPE SUBROUTINE s2(n) TYPE(t2(n)) :: y ... The type definition for T appears to conform to the standard; it allows an "automatic" component to be default initialized. However, the declaration of the local variable X in subroutine S will initialize the component differently depending on the value of N, for example, giving the CVALUE component the value "", "x", "xy", "xyz", "xyz " for N being 0, 1, 2, 3, 4 respectively. Q1. Was it intended that "automatic" components can be default-initialized? If the answer is "Yes", the type definition for T2 also appears to conform to the standard. However, the declaration of Y in S2 will not work if N has any value other than 10 at run time. This is surprising; there appears to be no other situation where the runtime value of a length type parameter can render a declaration invalid. Q2. Is this situation intentional? ANSWER: Q1. No, this was not intended. An edit is supplied to fix this. Q2. Not applicable. EDITS: In 4.5.3 Components, immediately before R445 , insert a new constraint: [50:40+] "C447a (R440) If appears, every type parameter and array bound of the component shall be an initialization expression." SUBMITTED BY: Malcolm Cohen HISTORY: 05-285 m174 F03/0072 Submitted 05-285r1 m174 Revised edit 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657