J3/00-202
Date: 19-Apr-2000
To: J3 Members
From: Interp/Stan Whitlock
Subj: F95 Interp letter ballot #1 (email x3j3.2000-136) due 19-May-2000
Enclosed in the first letter ballot on Fortran 95 interpretations.
The rules we operate on 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 a J3 letter ballot is equivalent to missing a J3
meeting, with subsequent negative effects on 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.
14 Fortran 95 interpretations have been passed at J3 meetings #150,
#151, and #152. This is the letter ballot phase to go from "passed
by J3 meeting" to "passed by J3 letter ballot".
The following Fortran 95 interpretations are being balloted:
Yes No Number Title
--- --- 000066 Errors in processing data transfer statements
--- --- 000067 Writing zeros
--- --- 000068 Asterisks as I/O units
--- --- 000069 What is a numeric character?
--- --- 000070 Asymmetry between constant specification and
initialization expressions
--- --- 000071 Character array constructors
--- --- 000072 Resolving generic procedure references
--- --- 000076 INTENT(IN) dummy arguments and implied DO loops
--- --- 000077 INTENT(IN) dummy arguments and NULLIFY
--- --- 000079 Pointer Assignment and Allocatable Arrays
--- --- 000080 Host association and the EXTERNAL attribute
--- --- 000082 Usage of BOZ literal constants
--- --- 000083 Scope of array-constructor implied-DO variable
--- --- 000084 Events that cause variables to be defined
The text of these interpretetions is attached. Each interpretation
starts with a row of "-"s.
Please mark the above "yes" or "no" answer {be sure to include your
reasons with "no"} and send only the above text {not this entire mail
mail message} to
x3j3@ncsa.uiuc.edu
by Midnight, PDT, Friday, 19-May-2000, in order to be counted.
Thanks /Stan
----------------------------------------------------------------------
NUMBER: 000066
TITLE: Errors in processing data transfer statements
KEYWORDS: ERR=; IOSTAT=; Data transfer statements
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
Consider the following program.
INTEGER :: A(10), IDX, J
OPEN(10, FORM='UNFORMATTED', ACCESS='SEQUENTIAL', STATUS='OLD',
&
& ACTION='READ')
READ(10, IOSTAT=IOS) IDX, J, A(IDX)
END
If an error occurs while processing the variable J in the data transfer
statement, does this program become non-standard conforming?
According to 9.4.3:
"If an error condition or an end-of-file condition occurs during
execution of an input/output statement, execution of the input/output
statement terminates and if the input/output statement contains any
implied-DOs, all of the implied-DO variables in the statement become
undefined. If an error condition occurs during execution of an
input/output statement, the position of the file becomes
indeterminate.
If an error or end-of-file condition occurs on input, all input list
items become undefined."
According to 9.4.4:
"The effect of executing a data transfer input/output statement shall
be as if the following operations were performed in the order
specified:
(1) Determine the direction of data transfer
(2) Identify the unit
(3) Establish the format if one is specified
(4) Position the file prior to data transfer (9.2.1.3.2)
(5) Transfer data between the file and the entities specified by the
input/output list (if any) or namelist
(6) Determine whether an error condition, an end-of-file condition,
or an end-of-record condition has occurred
(7) Position the file after data transfer (9.2.1.3.3)
(8) Cause any variables specified in the IOSTAT= and SIZE= specifiers
to become defined."
A simple reading of this seems to indicate that the point at which the error
occurs and is detected by a standard-conforming processor is unspecified.
Because IDX becomes undefined, the reference to IDX in the variable A(IDX)
is
incorrect. However, this is a very common style of coding I/O operations in
Fortran.
QUESTION 1:
Was it the committee's intent that such a program should not be standard-
conforming in the presence of an error condition?
QUESTION 2:
Does the fact that the error occurred before the item A(IDX) was processed
mean that there was no reference to IDX, and hence, that the program is
standard-conforming?
ANSWER 1: No.
ANSWER 2: Yes.
DISCUSSION: The referenced paragraph (9.4.4) is misleading. The entire
I/O list is not necessarily expected to be processed in the presence of an
error.
EDIT:
For Fortran 95:
In section 9.4.4, [150:32], in list item (5), change "or namelist"
to
"or namelist, until one of the end/error conditions described
in 9.4.3 occurs, or until the entire input/output list or
the namelist group has been processed"
For 99-007r2:
In Section 9.5.4, [203:36], in list item (6) of the first list,
change "or namelist" to
"or namelist, until one of the end/error conditions described in
section 9.5.3 occurs, or until the entire input/output list or
the namelist group has been processed"
and in section 9.6.2 (WAIT Operation), second paragraph [214:5],
insert the following after the first sentence.
"If an end/error condition described in section 9.5.3 occurs during
the data transfer, any remaining list items or namelist data objects
are not processed."
SUBMITTED BY: Henry Zongaro
HISTORY: J3/99-177 m150 submitted
J3/99-212 m150 approved uc
-------------------------------------------------------------------------------
NUMBER: 000067
TITLE: Writing zeros
KEYWORDS: list-directed output, namelist output
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
The standard currently requires a real zero to be
written in exponential form when using list-directed
or namelist output.
QUESTION: Is this requirement intentional or an oversight?
ANSWER: The requirement is an oversight.
DISCUSSION:
The G edit descriptor was changed in Fortran 90 to format a real zero as
if an F edit descriptor were provided in most cases. The same change
was not made for list-directed or namelist output, but should have.
REFERENCES: ISO/IEC 1539-1:1997(E),
Sections 10.5.4.1.2, 10.8.2, and 10.9.2.1
EDITS:
| For Fortran 95:
| In section 1.5.1, after the last paragraph, add the following as list
| item (3):
| (3) List directed and namelist output statements produce a real
| literal constant zero for a real value that is zero, and
| for the real or imaginary part of a complex value that is zero.
| In Fortran 95, these real literal constants are produced with
| the effect of an F edit descriptor, instead of an E edit
descriptor.
and in section 10.8.2 (List-directed output), fifth paragraph, [177:41],
change "If the magnitude x is within this range" to
"If the magnitude x is within this range or is zero"
and in section 10.9.2.1 (Namelist output editing), third paragraph,
[182:33], change "If the magnitude x is within this range" to
"If the magnitude x is within this range or is zero"
For 99-007r2 (Fortran 2000):
In section 1.5.2 (Fortran90 compatibility), add the following sentence
to the end of the first paragraph.
| "The following Fortran 90 features have different interpretations
| in this standard."
and in section 1.5.2, turn the 2nd paragraph into list item (1),
and add the following after the 2nd paragraph as list item (2).
| (2) List directed and namelist output statements produce a real
| literal constant zero for a real value that is zero, and
| for the real or imaginary part of a complex value that is zero.
| In Fortran 2000, these real literal constants are produced with
| the effect of an F edit descriptor, instead of an E edit
descriptor.
and in section 10.9.2 (List-directed output), fifth paragraph, [246:10],
change "If the magnitude x is within this range" to
"If the magnitude x is within this range or is zero"
and in section 10.10.2.1 (Namelist output editing), third paragraph,
[251:4], change "If the magnitude x is within this range" to
"If the magnitude x is within this range or is zero"
SUBMITTED BY: Robert Corbett
HISTORY: J3/99-193 m150 Submitted
J3/99-213r1 m150 approved uc
-------------------------------------------------------------------------------
NUMBER: 000068
TITLE: Asterisks as I/O units
KEYWORDS: Asterisk, I/O, unit
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
Question:
1. Does the Fortran 95 standard require the external unit
corresponding
to the I/O unit identified by an asterisk for input or output to
be
the same as the external unit identified by some fixed nonnegative
integer value?
2. Can the I/O unit identified by an asterisk for input or output
correspond to more than one external unit?
3. If the external unit identified by an integer value that
corresponds
to the I/O unit identified by an asterisk for input or output is
closed, does that cause the I/O unit identified by an asterisk to
become disconnected?
Answer:
1. No.
2. No.
3. Yes.
Discussion:
The submitter states: At least one Fortran 95 implementation uses -1 as
the
value of the I/O unit identified by an asterisk. A carefully constructed
INQUIRE statement can expose this value to the user. Many users expect I/O
to
the units identified by asterisks to continue to work even after the
corresponding units identified by integer values have been closed.
1. There is no requirement in the standard that the asterisk
correspond
to an external-file-unit.
2. For the units identified by the asterisk, the text of section
9.3.2
does not allow two or more units to be connected simultaneously to the same
external device or file [139:8-9]. An edit is supplied to clarify this
situation.
3. There might not be an external-file-unit that corresponds to the
io-unit specified by an asterisk, as clarified by the edit below. If there
is,
it is permissible to execute a CLOSE statement on them as on any other unit.
REFERENCES: ISO/IEC 1539-1:1997(E), Sections 9.3 and 9.4.4.2
EDITS:
For Fortran 95:
Add the following text to the end of the last paragraph before section
9.3.1
[138:34+]:
"An asterisk used in an input statement may identify the same
io-unit
as a particular external-file-unit. An asterisk used in an
output
statement may identify the same io-unit as another particular
external-file-unit."
There are no edits required for Fortran 2000.
SUBMITTED BY: Robert Corbett
HISTORY:
99-192 m150 Submitted
99-215r1 m150 approved uc
-------------------------------------------------------------------------------
NUMBER: 000069
TITLE: What is a numeric character?
KEYWORDS: list-directed input
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
Section 10.8.1 of
the Fortran 95 standard states
If the next effective item is of type default
character and ...
(4) The leading characters are not
numeric followed by an asterisk, ...
The standard does not define what a numeric character is.
QUESTION:
What is a numeric character?
ANSWER:
A numeric character is a digit.
REFERENCES: ISO/IEC 1539-1:1997(E), Section 10.8.1
EDITS:
In Fortran 95, section 10.8.1, list item (4), [176:17],
replace the text
(4) The leading characters are not numeric followed by an asterisk
with
(4) The leading characters are not digits
followed by an asterisk
In 99-007r2, section 10.9.1, list item (4), [244:32],
replace the text
(4) The leading characters are not numeric followed by an asterisk
with
(4) The leading characters are not digits
followed by an asterisk
SUBMITTED BY: Robert Corbett
HISTORY: J3/99-191 m150 Submitted by Robert Corbett
J3/99-214 m150 J3 draft response, approved uc
-------------------------------------------------------------------------------
NUMBER: 000070
TITLE: Asymmetry between constant specification and initialization
expressions
KEYWORDS: Initialization expressions; specification expressions
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Consider the following programs.
PROGRAM P1
REAL :: B = 4.0*ATAN(1.0)
PRINT *, B
END PROGRAM P1
PROGRAM P2
INTEGER :: A(INT(4*ATAN(1.0))) = 17
PRINT *, A
END PROGRAM P2
According to 7.1.6.1 program unit P1 is not standard-conforming because of
the
reference to the intrinsic function ATAN which is not permitted in an
initialization expression.
According to 7.1.6.2 program unit P2 is standard-conforming; the reference
to
the intrinsic function ATAN is allowed by item (8) in the definition of a
restricted expression. Expressions in the array bounds of an initialized
entity are only required to be constant specification expressions, not
initialization expressions.
Was it the committee's intent to permit ATAN to appear in the array bounds
of
an initialized entity but not in the initialization value?
ANSWER:
No, this was not the intent. These expressions should have been described
as initialization expressions instead of as constant expressions.
This error also occurs for the definitions of an automatic entity, common
block
definitions and component definitions.
The edits below change all of these to require initialization expressions
instead of constant expressions.
EDIT:
[39:15] Change "a constant specification" to "an initialization".
{Fix array components.}
[39:23] Change "a constant specification" to "an initialization".
{Fix character string components.}
[40:30] Change "a constant" to "an initialization".
{Fix note.}
[48:47-48] Change "may be a nonconstant expression provided the
specification
expression"
to "shall be an initialization expression unless it".
[49:1-3] Delete "If a ... nonconstant expression."
[49:4-5] Change "such a nonconstant expression"
to "a that is not an initialization
expression".
{Fix definition of "automatic object".}
[49:9] Change "a nonconstant expression"
to "an expression that is not an initialization expression".
{Fix evaluation time for character length.}
[51:33] Change "a constant specification" to "an initialization".
{Fix statement function character lengths.}
[54:33] Change "nonconstant specification" to "not initialization".
{Fix automatic array definition.}
[54:34] Change "nonconstant specification" to "not initialization".
{Fix evaluation time for explicit-shape array bounds.}
[56:32] Change "nonconstant specification" to "not initialization".
{Fix evaluation time for assumed-size array bounds.}
[69:3-4] Change "a constant specification expression (7.1.6.2)"
to "an initialization expression (7.1.6.1)".
{Fix common block array-specs.}
[192:26] Change "a constant" to "an initialization".
{Fix characteristics of function results.}
SUBMITTED BY: Henry Zongaro
HISTORY: 99-178 m150 submitted
99-216r1 m150 approved uc
00-133 m152 additional edit, approved uc
-------------------------------------------------------------------------------
NUMBER: 000071
TITLE: Character array constructors
KEYWORDS: Character, array constructor, zero-size
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
The f95 standard appears to leave the length of zero-sized character array
constructors undefined. The penultimate paragraph of clause 4.5 says
"The type and parameters of an array constructor are those of the
expressions."
If there are no elements, then the values of the type parameters might not
be
defined. The type and kind are always well defined at compile time.
However,
the length parameter for zero-sized character array constructors is not
obviously well-defined, even at run-time.
Zero-sized constructors are certainly allowed, as mentioned in the
antipenultimate paragraph of clause 4.5:
"An empty sequence forms a zero-sized rank-one array."
Experimentation with different f90 compilers yields varying results.
QUESTION 1:
Is the following a valid program and, if so, what len value does it print.
program zero
write (*,*) len( (/ ('abc', i = 1 , 0) /) )
end
QUESTION 2:
Is the following a valid program and, if so, what value does it print.
program zero_size
integer :: n = 0
call sub('abcdefghij', n)
contains
subroutine sub(string, n)
character*(*) :: string
integer :: n
integer :: i
write (*,*) len( (/ (string(:i+2), i = 1 , n) /) )
end subroutine
end program zero_size
QUESTION 3:
Is the following a valid program and, if so, what values does it print
for the lengths and for n_calls.
program zero_size
integer :: n = 0
integer :: n_calls = 0
call sub('abcdefghij', n)
write (*,*) 'n_calls = ', n_calls
contains
subroutine sub(string, n)
character*(*) :: string
integer :: n
integer :: i
write (*,*) len( (/ (string(:f(i)), i = 1 , n), 'abcde' /) )
end subroutine sub
integer function f(i)
f = 2*i + 5
n_calls = n_calls + 1
end function f
end program zero_size
ANSWER:
(1) Yes. The length is 3.
Clause 4.5 says that
"The type and type parameters of an array constructor are those of
the
expressions."
There is no exclusion for s that contribute no elements to the
value of the array constructor: thus s that are inside
zero-trip
implied DO loops still contribute their "type" information.
The example array constructor has an that is the character
literal 'abc'; this clearly has the character length of 3 and therefore
the array constructor has a character length of 3.
The description of how an that is an implied DO is handled
confuses syntax and semantics: an edit is supplied to clarify this.
(2) No. The edits below clarify this situation.
(3) Yes. The length printed is 5, n_calls is still zero.
Clause 4.5 says that
"If the expressions are of type character, each
expression in the shall have the same character
length parameter."
The example array constructor has an that is the character
literal 'abcde'; this clearly has the character length of 5 and
therefore
the array constructor has a character length of 5.
No references to the function F are executed because these appear within
a zero-trip implied DO loop.
EDITS:
In clause 4.5, in the paragraph beginning
"If an is a scalar expression"
[46:1] replace:
"an sequence"
with
"a sequence of elements".
In clause 4.5, at the end of the paragraph which begins "If the
expressions are of type character" [45:38+], insert:
"A zero-sized character array constructor shall have at least one
that is an initialization expression, a that does not contain
a , or a containing a in
which all expressions are initialization expressions."
SUBMITTED BY: Richard Maine
HISTORY: 98-101 m144 submitted 20 Nov 1997
99-207 m150 additional input
99-217r3 m150 approved uc
-------------------------------------------------------------------------------
NUMBER: 000072
TITLE: Resolving generic procedure references
KEYWORDS: generic, ELEMENTAL
DEFECT TYPE:
STATUS: Passed by J3 meeting
QUESTION:
Consider
INTERFACE generic
ELEMENTAL SUBROUTINE sub_e(a)
REAL,INTENT(INOUT) :: a
END
SUBROUTINE sub_3(a)
REAL,INTENT(INOUT) :: a(:,:,:)
END
END INTERFACE
This is legal (it obeys the restrictions in 14.1.2.3).
This allows the ambiguous reference
REAL x(10,20,30)
CALL generic(x)
However, the existing text in 14.1.2.4.1 does not explain which procedure is
called, because the reference is consistent with two procedures. Note 14.6
indicates that the intent is to call the non-elemental procedure in this
case.
Is note 14.6 correct as to the intent of the standard?
ANSWER:
Yes, note 14.6 is correct; an edit is supplied to the resolution rules to
implement this.
EDIT:
[278:41] After "with" insert "a non-elemental reference to".
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-218 m150 submitted, approved uc
-------------------------------------------------------------------------------
NUMBER: 000076
TITLE: INTENT(IN) dummy arguments and implied DO loops
KEYWORDS: INTENT(IN), implied DO
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
The Fortran 95 standard [53:13-17] says
"Constraint: A dummy argument with the INTENT(IN) attribute ... shall not
appear as
...
(3) A DO variable or implied-DO variable,
..."
The apparent intent is to prevent any modification of the dummy argument;
however, use in data-implied-do and array-constructor-implied-do would not
modify the dummy argument.
Is the constraint intentionally stronger than necessary?
ANSWER:
The constraint is only intended to apply to implied-DO variables in I/O
lists.
The following edit makes this clearer.
EDIT:
[53:17] Change "A DO variable or implied-DO variable"
to "The in a or ".
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-199 m150 submitted
99-199r1 m150 approved uc
-------------------------------------------------------------------------------
NUMBER: 000077
TITLE: INTENT(IN) dummy arguments and NULLIFY
KEYWORDS: INTENT(IN), NULLIFY
DEFECT TYPE:
STATUS: Passed by J3 meeting
QUESTION:
The Fortran 95 standard [53:13-17] says
"Constraint: A dummy argument with the INTENT(IN) attribute, or a subobject
of
such a dummy argument, shall not appear as
...
(2) The of a ,
..."
Consider:
TYPE t
REAL,POINTER :: value
END TYPE
...
SUBROUTINE s(x)
TYPE(t),INTENT(IN) :: x
IF (.FALSE.) x%value => NULL() ! (1)
IF (.FALSE.) NULLIFY(x%value) ! (2)
According to the constraint above, line (1) is illegal.
However, there is no corresponding constraint for the NULLIFY statement,
implying that line (2) is legal.
Should subobjects of INTENT(IN) dummies also be constrained against
appearing as the of a NULLIFY statement?
ANSWER:
Yes, there should be a constraint disallowing INTENT(IN) dummy arguments in
a NULLIFY statement. The edit below corrects this omission.
EDIT:
[53:16] After ""
insert "or ".
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-200 m150 submitted
99-200r1 m150 approved uc
-------------------------------------------------------------------------------
NUMBER: 000079
TITLE: Pointer Assignment and Allocatable Arrays
KEYWORDS: Character, array constructor, zero-size
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
Consider
PROGRAM p
REAL,ALLOCATABLE,TARGET :: x(:)
POINTER p(:)
p => x
ALLOCATE(x(10))
PRINT *,SIZE(p)
END
This appears to be a legal program - there seems to be no prohibition
against
pointer assignment to an unallocated allocatable array and allocating the
array
does not seem to alter the association status of any pointer associated with
an
allocatable array.
Should there be a prohibition against pointer assignment to an unallocated
allocatable array?
ANSWER:
Yes; an edit is supplied to correct this oversight.
EDIT:
In clause 7.5.2, at the end of the paragraph that begins "The
shall"
[111:8+], insert:
"If the is an allocatable array it shall be currently
allocated."
EDIT to 99-007r2:
[156:7+] add to end of paragraph:
"If the is allocatable it shall be currently allocated."
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-223 m150 submitted, approved 6-4
-------------------------------------------------------------------------------
NUMBER: 000080
TITLE: Host association and the EXTERNAL attribute
KEYWORDS: Host association, EXTERNAL
DEFECT TYPE:
STATUS: Passed by J3 meeting
QUESTION:
Use of a (non-intrinsic) name as a procedure in a procedure reference
implicitly confers the EXTERNAL attribute on the name. Does this happen
when the name is host-associated?
For example, f90 interp 143 established that
MODULE m1
REAL x
CONTAINS
SUBROUTINE s
PRINT *,x(1)
END SUBROUTINE
END
was invalid - 11.3.2 now says that a "procedure with implicit interface and
public accessibility shall explicitly be given the EXTERNAL attribute in the
scoping unit of the module".
However, this text says nothing about private entities, so considering:
MODULE m2
REAL,PRIVATE :: x
CONTAINS
SUBROUTINE s
PRINT *,x(1)
END SUBROUTINE
END
This example does not violate 11.3.2 because X is PRIVATE.
Is this example conforming?
Further, considering:
PROGRAM m3
REAL x
CONTAINS
SUBROUTINE s
PRINT *,x(1)
END SUBROUTINE
END
This example is not of a module and so 11.3.2 does not apply.
Is this example conforming?
Further, considering
PROGRAM m4
EXTERNAL x
CONTAINS
SUBROUTINE s
PRINT *,x(1)
END SUBROUTINE
END
Does the invocation as a function in an internal procedure cause X to be
implicitly typed, or is this not conforming?
ANSWER:
No, use of a host-associated name never confers attributes on the host
entity.
Examples M2, M3, and M4 are therefore invalid.
Edits are supplied.
EDIT:
[188:28] Delete "and public accessibility".
[188:31] Delete "with public accessibility".
[283:16+] Add new paragraph
"A procedure with an implicit interface that is accessed via host
association
shall explicitly be given the EXTERNAL attribute in the host scoping unit
or
be used as a procedure in that scoping unit; if it is invoked as a function
in the inner scoping unit, its type and type parameters shall be explicitly
declared in a type declaration statement in the host scoping unit. An
intrinsic procedure that is accessed via host association shall explicitly
be
given the INTRINSIC attribute in the host scoping unit or be used as an
intrinsic procedure in that scoping unit."
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-230 m151 submitted
99-230r1 m151 approved uc
-------------------------------------------------------------------------------
NUMBER: 000082
TITLE: Usage of BOZ literal constants
KEYWORDS:
DEFECT TYPE:
STATUS: Passed by J3 meeting
QUESTION:
Consider:
INTEGER X(10)
DATA X(B"001")/42/
END
This is apparently conforming, since the constraint at [32:15] says
"A may appear only in a DATA statement."
But this rules out
X(B"001") = 42
Is this an error?
ANSWER:
Yes, BOZ literal constants should be restricted to being a
.
EDITS:
[32:15] Replace text of constraint with
"A may appear only as the in a
DATA statement."
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-275 m151 submitted
99-275r1 m151 approved uc
-------------------------------------------------------------------------------
NUMBER: 000083
TITLE: Scope of array-constructor implied-DO variable
KEYWORDS: Scope, implied DO, array constructor
DEFECT TYPE:
STATUS: Passed by J3 meeting
QUESTION:
14.1.3 states that the scope of an implied-DO variable in an array
constructor
is "the implied-DO list". There is no such syntax term: what is meant?
In particular, in the array constructor
(/ (I,I=1,I) /)
are all three I's references to the implied-DO variable, or is one of them
a reference to a variable I in the enclosing scoping unit?
ANSWER:
All occurences of I within the implied-DO are references to the implied-DO
variable, none of them can reference a variable in the enclosing scoping
unit.
The term "implied-DO list" is confusing in this context; "implied-DO" was
intended. An edit is supplied for clarification.
DISCUSSION:
The term "implied-DO list" is used in several places where the context is
that of the values produced by the implied-DO. This is an inappropriate
term to use for specifying scope.
Also, the second and third occurrences of "I" in the example shown are part
of
the syntax item . It would be unreasonable to read
"implied-DO list" as meaning (for array constructors) " and
the
in but not the s
in
."
Note that the problem does not arise for because variables
other than implied-DO variables are not permitted in the limit expressions.
With this interpretation the example array constructor supplied is not valid
Fortran, as it is not permissible to reference the value of an
variable in one of its limit expressions.
EDITS:
[280:41] Replace "implied-DO list" with "implied-DO".
SUBMITTED BY: Malcolm Cohen
HISTORY: 00-124 m152 Submitted
00-124r1 m152 approved uc
-------------------------------------------------------------------------------
NUMBER: 000084
TITLE: Events that cause variables to be defined
KEYWORDS: Definition status, INTENT(OUT)
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Item (6) of 14.7.5 says
"A reference to a procedure causes the entire dummy argument to become
defined if the entire corresponding actual argument is defined with a
value
that is not a statement label.
A reference to a procedure causes a subobject of a dummy argument to
become
defined if the corresponding subobject of the corresponding actual
argument
is defined."
For an INTENT(OUT) dummy this appears to conflict with 14.7.6 item (13)(b)
"When a procedure is invoked ...
(b) A dummy argument with INTENT(OUT) is undefined except for any
nonpointer
direct components of the argument for which default initialization is
specified."
So in
X = 3
CALL S(X)
...
SUBROUTINE S(A)
INTENT(OUT) A
...
Is A defined (with the value 3) in accordance with 14.7.5, or undefined in
accordance with 14.7.6?
Similarly, for subobjects of INTENT(OUT) dummies, does 14.7.5 take
precedence
or 14.7.6?
ANSWER:
A is undefined in accordance with 14.7.6. An edit is supplied to remove the
conflict. Similarly, 14.7.6 takes precedence for subobjects.
EDITS:
To Fortran 95:
[289:9] Before "entire"
insert "dummy argument does not have INTENT(OUT) and the".
[289:12] Before "corresponding"
insert "dummy argument does not have INTENT(OUT) and the".
To draft Fortran 2002:
No edits required (above fixes already incorporated).
SUBMITTED BY: Malcolm Cohen
HISTORY: 00-141 m152 submitted, approved uc
-------------------------------------------------------------------------------