J3/06-111 Date: 29-Dec-2005 To: J3 Members From: interp/Stan Whitlock Subj: J3 Fortran interp letter ballot #12 - due 3-Feb-2006 Enclosed in the twelfth letter ballot on Fortran interpretations. The rules by which we operate say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 17 Fortran 2003 interpretations are currently "Passed by J3 meeting" after J3 meeting #174. This is the letter ballot phase to go from "Passed by J3 meeting" to "Passed by J3 letter ballot". The following Fortran interpretations are being balloted: Yes No Number Title --- --- F03/0028 Commas in complex namelist output --- --- F03/0045 Finalization and assumed-sized arguments with INTENT(OUT) --- --- F03/0056 Null input values and list-directed UDDTIO --- --- F03/0057 Namelist I/O and UDDTIO --- --- F03/0058 Recursive namelist output --- --- F03/0059 Structure components in namelist input --- --- F03/0060 Default initialization of INTENT(OUT), assumed-size arrays {subsumed by F03/0045} --- --- F03/0061 Polymorphism and explicit-shape or assumed-size dummy arguments --- --- F03/0062 Finalization of array constructors --- --- F03/0063 Procedure pointers in BLOCK DATA program units --- --- F03/0064 Recursive declaration of procedure interfaces --- --- F03/0066 Precision of operation --- --- F03/0067 Accuracy of conversion of real literal constants --- --- F03/0068 First character of namelist output records --- --- F03/0069 Procedure pointers in defined assignment --- --- F03/0070 Can child I/O statements be advancing I/O statements? --- --- F03/0072 Default initialization for "automatic" components 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 message} with any comments to j3@j3-fortran.org by 11:59:59PM, PST, Friday, 3-Feb-2006, in order to be counted. Thanks /Stan ---------------------------------------------------------------------- NUMBER: F03/0028 TITLE: Commas in complex namelist output KEYWORDS: Namelist, complex formatting, comma, semicolon DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 ---------------------------------------------------------------------- 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 J3 meeting 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 ---------------------------------------------------------------------- NUMBER: F03/0056 TITLE: Null input values and list-directed UDDTIO KEYWORDS: null value, UDDTIO DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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 ---------------------------------------------------------------------- NUMBER: F03/0057 TITLE: Namelist I/O and UDDTIO KEYWORDS: namelist, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 ---------------------------------------------------------------------- NUMBER: F03/0058 TITLE: Recursive namelist output KEYWORDS: UDDTIO, namelist, output DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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 ---------------------------------------------------------------------- NUMBER: F03/0059 TITLE: Structure components in namelist input KEYWORDS: Namelist, UDDTIO, component DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 dtv%j = dtv%i * 2 END SUBROUTINE END MODULE PROGRAM p USE m TYPE(t) :: x NAMELIST /nml/ x READ (*, nml) PRINT *, x%i, x%j END PROGRAM Question 1: Is the following input valid for the above program? &nml b1%i = 100 / Question 2: If the input is valid, what is the output of the program, when using this input? ANSWER: 1. No, this input is not valid for the given program. The name of a component of a structure should not appear in namelist input if that structure would be processed by a user-defined derived-type I/O procedure. Edits are supplied to correct this oversight. 2. N/A EDITS: [243:24-27] Replace "If the namelist group object name is the name of a variable of derived type, the name in the input record may be either the name of the variable or the designator of one of its components, indicated by qualifying the variable name with the appropriate component name." with "If the namelist group object is a variable of derived type, the name in the input record may be the name of the variable. If the variable would not be processed by a user-defined derived-type input/output procedure, the name in the input record may also be the designator of one of its components, using the syntax of object designators." SUBMITTED BY: Rob James HISTORY: 05-174 m172 F03/0059 Submitted 05-221 m173 Passed by J3 meeting ---------------------------------------------------------------------- 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 J3 meeting 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 ---------------------------------------------------------------------- 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 J3 meeting 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 ---------------------------------------------------------------------- NUMBER: F03/0062 TITLE: Finalization of array constructors KEYWORDS: Finalization, array constructor DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 the first occurrence 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 ---------------------------------------------------------------------- NUMBER: F03/0063 TITLE: Procedure pointers in BLOCK DATA program units KEYWORDS: Procedure pointer, common block, block data DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: It is clear that procedure pointers are permitted in common blocks. However, due to the restrictions on BLOCK DATA program units, it seems that such a common block can not appear in a BLOCK DATA program unit. Was it intended that common blocks containing procedure pointers could be initialized in a BLOCK DATA program unit? ANSWER: Yes, it was intended that common blocks containing procedure pointers could be initialized in a BLOCK DATA program unit. Edits are provided to correct this oversight. EDITS: All edits refer to 04-007. [253:12] After "derived-type definitions", insert ", abstract interface blocks,". [253:14] Before "and type declaration", insert "procedure declaration statements,". [254:3] After "specifiers", insert "if it declares a data object". [254:1] Append a new sentence: A procedure declaration statement shall not declare an external procedure. SUBMITTED BY: Rob James HISTORY: 05-178 m172 F03/0063 Submitted 05-225 m173 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0064 TITLE: Recursive declaration of procedure interfaces KEYWORDS: procedure, interface DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: PROGRAM foo PROCEDURE(sub) :: p INTERFACE SUBROUTINE sub(p2) IMPORT p PROCEDURE(p) :: p2 END SUBROUTINE END INTERFACE END PROGRAM C1212 appears to prohibit the case of an interface name in a procedure declaration statement being the name of something declared in a later procedure declaration statement. But it does not appear to prohibit the case of an interface name being the name of something declared in a later interface body. In the above program, the characteristics of p rely on the characteristics of sub. The characteristics of sub, in turn, rely on the characteristics of p. Is this program standard-conforming? ANSWER: No, this program is not standard-conforming. The interface name in a procedure declaration statement should not be permitted to be declared in a later interface body. An edit is supplied to correct this oversight. EDITS: All edits refer to 04-007. [264:22] Before "it shall", insert "or ". SUBMITTED BY: Rob James HISTORY: 05-179 m172 F03/0064 Submitted 05-226 m173 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0066 TITLE: Precision of operation KEYWORDS: precision, operation DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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 ---------------------------------------------------------------------- NUMBER: F03/0067 TITLE: Accuracy of conversion of real literal constants KEYWORDS: conversion, accuracy DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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 ---------------------------------------------------------------------- NUMBER: F03/0068 TITLE: First character of namelist output records KEYWORDS: namelist, output, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 ---------------------------------------------------------------------- NUMBER: F03/0069 TITLE: Procedure pointers in defined assignment KEYWORDS: procedure pointer, defined assignment DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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 ---------------------------------------------------------------------- NUMBER: F03/0070 TITLE: Can child I/O statements be advancing I/O statements? KEYWORDS: UDDTIO, ADVANCE= DEFECT TYPE: Erratum STATUS: Passed by J3 meeting [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 " non-child". [189:9] Replace "from an" with "from a non-child". [189:9] After "YES." Insert " A child input/output statement is a non-advancing input/output statement, and any ADVANCE= specifier is ignored." SUBMITTED BY: Rob James HISTORY: 05-229 m173 F03/0070 Submitted 05-229r1 m173 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F03/0072 TITLE: Default initialization for "automatic" components KEYWORDS: Parameterized Derived Type, Default Initialization DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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(t(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. 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 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 ----------------------------------------------------------------------