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
----------------------------------------------------------------------