(j3.2006) J3 Fortran interp letter ballot #17 - due 25-Jul-2008
Whitlock, Stan
stan.whitlock
Sun Jun 22 17:34:58 EDT 2008
08-213
To: J3 Members
From: Stan Whitlock
Subject: J3 Fortran interp letter ballot #17 - due 25-Jul-2008
Date: 22-Jun-2008
Enclosed in the next 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.
15 Fortran interpretations are currently "Passed by J3 meeting" after
J3 meeting #184. 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
--- --- F95/0074 TARGET dummy arguments and POINTER expressions
--- --- F95/0102 mask-expr evaluated only once
--- --- F03/0049 Separators in list-directed output involving
UDDTIO
--- --- F03/0071 Subroutine/function ambiguity in generics
--- --- F03/0073 C interop of dummy procedures
--- --- F03/0074 Type mismatch for C character arguments
--- --- F03/0075 C interop of derived types with array components
--- --- F03/0076 Scope of Fortran names of procedures with binding
labels
--- --- F03/0077 LBOUND of array structure component
--- --- F03/0081 F edit descriptor with field width 0
--- --- F03/0082 VALUE in place of INTENT for pure procedure dummy
arguments
--- --- F03/0087 Entry names as dummy procedure arguments
--- --- F03/0098 Does allocate with source= define subcomponents?
--- --- F03/0112 attributes allowed for dummy arguments in defined
assignments
--- --- F03/0117 STOP executed via function in input/output list
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 at j3-fortran.org
by 11:59:59PM, PDT, Friday, 25-Jul-2008, in order to be counted.
Thanks /Stan
----------------------------------------------------------------------
NUMBER: F95/0074
TITLE: TARGET dummy arguments and POINTER expressions
KEYWORDS: TARGET, POINTER, dummy arguments
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
see also F95 interp 000031
QUESTION:
Consider the following program.
PROGRAM questionable
REAL,TARGET :: x
CALL s1(f(x))
CALL s2(f(x))
CALL s3(f(x))
CONTAINS
FUNCTION f(a)
REAL,POINTER :: f
REAL,TARGET :: a
f => a
END FUNCTION
SUBROUTINE s1(variable)
variable = 42 ! statement 1
END SUBROUTINE
SUBROUTINE s2(variable)
INTENT(OUT) variable
variable = 42 ! statement 2
END SUBROUTINE
SUBROUTINE s3(targ)
REAL,TARGET :: targ
REAL,POINTER :: p
p => targ
PRINT *,ASSOCIATED(p,x) ! statement 3
END SUBROUTINE
END
Is this program standard-conforming, and if so, what value is
printed?
The real question is whether an expression argument that is a pointer
function reference is treated as a variable (data-object) argument
with the variable being the target of the pointer expression. (Or
whether it is dereferenced as usual in the absence of POINTER dummy
arguments).
Re (statement 1), the question is whether VARIABLE is definable when
argument-associated with "F()".
Re (statement 2), if the previous answer was Yes (VARIABLE is
definable), then presumably it can be made INTENT(OUT). A random
sample of 4 compilers revealed that they considered it not to be
definable.
Re (statement 3), the question is whether P is pointer-associated
with X, not pointer-associated with X, or processor-dependent. Of
the same random sample 3 thought it was associated with X, 1 thought
not.
ANSWER:
These answers are in the context of Fortran 2003.
1. The call to s1 is not standard conforming. 5.1.2.7 states
"If no INTENT attribute is specified for a dummy argument, its use
is subject to the limitations of the associated actual argument."
The associated actual argument is the function reference f(x); this
is an expression, not a variable, and therefore not definable,
because only variables can be defined (in the sense of being given
a value, see 2.4.3.1.1 and 2.5.5).
2. The call to s2 is not standard conforming. 12.4.1.2 says:
"If a nonpointer dummy argument has INTENT(OUT) or INTENT(INOUT),
the actual argument shall be definable."
Again the actual argument is a function reference, which is not
definable.
3. The call to s3 is standard conforming and the pointer assignment in
s3 causes p and x to become associated. This may be deduced from
12.4.1.2, which says [270:5-0]
"If the dummy argument has the TARGET attribute, does not have
the VALUE attribute, and is either a scalar or an assumed-shape
array, and the corresponding actual argument has the TARGET
attribute but is not an array section with a vector subscript
then
(1) Any pointers associated with the actual argument become
associated with the corresponding dummy argument on
invocation of the procedure ..."
EDITS: None.
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-198 m150 F95/0074 submitted
WG5/N1414 Draft answer
00-260 m154 Passed by J3 meeting
00-329 m155 Failed J3 letter ballot
04-311 m168 Passed by J3 meeting vote - alternate
answer removed
04-417r1 M170 Passed by J3 letter ballot #8
05-180 m172 Failed WG5 ballot N1617
08-172 m184 Revised answer - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F95/0102
TITLE: mask-expr evaluated only once
KEYWORDS: WHERE
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
QUESTION:
Is a mask-expr required to be evaluated in a WHERE such as:
WHERE ( (/ .TRUE., .TRUE. /) )
A = A + 1
ELSE WHERE (MASKF())
A = MAX
END WHERE
where an optimizing compiler might notice that the ELSEWHERE
branch will never be executed ?
Page 112, line 38 says of the mask expression in ELSEWHERE statements
"The mask-expression is evaluated only once."
ANSWER:
The above quote is from the Fortran 95 standard. In Fortran 2003 the
mask expression in an ELSEWHERE is not required to be evaluated, and
this is made clear by the fourth paragraph of 7.4.3.2 (at [147:7])
which, referring to a masked ELSEWHERE statement, states
"The <mask-expr> is evaluated at most once."
This also applies to the mask expressions of nested WHERE construct
statements; this is made clear by the last sentence of the seventh
paragraph of 7.4.3.2 (at [147:16]) which also states that it is
evaluated "at most once".
However, this does not apply to the mask expression of the outermost
WHERE construct statement, which must be evaluated exactly once; this
is made clear by the last statement of the first paragraph of 7.4.3.2
(at [147:1]) which states that this mask expression is evaluated "only
once". That does not guarantee invocation of functions in that
expression if they are not required to determine its value.
EDITS:
None.
SUBMITTED BY: Matthijs van Waveren
HISTORY: 03-239 m165 F95/0102 Passed by J3 meeting
04-417r1 m170 Passed by J3 letter ballot #8
05-180 m172 Failed WG5 ballot N1617
08-171 m184 Revised answer - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0049
TITLE: Separators in list-directed output involving UDDTIO
KEYWORDS: list-directed output, separators, UDDTIO
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Consider the following program:
MODULE m
TYPE t
INTEGER i
END TYPE
INTERFACE WRITE(FORMATTED)
MODULE PROCEDURE formattedWriteT
END INTERFACE
CONTAINS
SUBROUTINE formattedWriteT(dtv, unit, iotype, v_list, iostat, iomsg)
CLASS(t), INTENT(IN) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(LEN=*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(LEN=*), INTENT(INOUT) :: iomsg
WRITE(unit, *) dtv%i, 'a'
END SUBROUTINE
END MODULE
PROGRAM foo
USE m
TYPE(t) :: t1 = t(5)
OPEN(10, FILE='foo.txt', ACCESS='SEQUENTIAL', FORM='FORMATTED', &
DELIM='NONE')
WRITE(10, *) 'xyz', t1, 'zyx'
END PROGRAM
10.9.2 of Fortran 2003 states that character sequences produced for
list-directed output are not separated from each other by value
separators when the delimiter mode is NONE. The implication of this
is obvious when the adjacent effective output list items are both of
character type. But when user-defined derived-type input/output
is involved, it is much less clear whether a separator should be
included in the output.
In the example given, it is unclear whether the output should be:
xyz 5 azyx
or:
xyz 5 a zyx
1. Should a separator be inserted between two non-delimited character
sequences when one of the character sequences is written by a child
data transfer statement, and the other is written by a parent data
transfer statement, where both statements are list-directed?
2. Should a separator be inserted between two non-delimited character
sequences when the character sequences are written by two different
child data transfer statements, where both statements are
list-directed?
3. Should a separator be inserted between two character sequences when
one of the character sequences is written by a child data transfer
statement, and the other is written by a parent data transfer
statement, where one of the statements is list-directed and the
other is format-directed?
4. Should a separator be inserted between two character sequences when
the character sequences are written by two different child data
transfer statements, where one of the statements is list-directed
and the other is format-directed?
There is also the further question of whether, in the case of
recursive i/o, this is affected by intervening i/o operations to a
different unit. For example, in the modified program:
MODULE m2
TYPE t
INTEGER i
END TYPE
INTERFACE WRITE(FORMATTED)
MODULE PROCEDURE formattedWriteT
END INTERFACE
CONTAINS
SUBROUTINE formattedWriteT(dtv,unit,iotype,v_list,iostat,iomsg)
CLASS(t), INTENT(IN) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(LEN=*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(LEN=*), INTENT(INOUT) :: iomsg
CHARACTER(100) temp
WRITE (temp,'(I0)') dtv%i
WRITE (unit,*) TRIM(temp)
END SUBROUTINE
END MODULE
PROGRAM foo2
USE m2
TYPE(t) :: t1 = t(5)
OPEN(10, FILE='foo.txt', ACCESS='SEQUENTIAL', &
FORM='FORMATTED', DELIM='NONE')
WRITE(10, *) 'xyz', t1, 'zyx'
END PROGRAM
5. Does the second example write
xyz 5xyz
or
xyz5xyz
That is, in this case, does the data transfer which is an internal
file write affect whether 'xyz' and TRIM(temp) are adjacent?
6. Similarly, if the outer list-directed WRITE were to an internal
file does an intervening external file i/o operation affect whether
the character sequences are considered adjacent (i.e. the opposite
way around to the second example)?
ANSWER:
1) No. It is the intent of the standard (10.9.2) that when both the
parent and child data transfer statements are both list-directed
output statements, or both are namelist output statements, the
processor treats the first list item appearing in a child data
transfer statement as if that list item had immediately
followed the last list item processed by the parent data
transfer statement, as long as no other data transfers to that
unit occurred in between the processing of those two list items.
Therefore, in this case, the two character sequences are
considered adjacent.
2) No. It is the intent of the standard (10.9.2) that when two
different child data transfer statements are both list-directed
output statements, or both namelist output statements, they write
to the same unit, and no other data transfers to that unit occur
in between the two child data transfer statements, the processor
treats the first list item appearing in the second child data
transfer statement as if that list item had immediately followed
the last list item processed by the first child data transfer
statement. Therefore, in this case, the two character sequences
are considered adjacent.
3) It is processor dependent whether or not a separator appears
between two such character sequences. In section 10.9.2, the
phrase "adjacent undelimited character sequences" refers to
character sequences produced by list-directed output. When one of
the sequences is written by a child or parent output statement
that is not list-directed, the exception described in the first
paragraph of 10.9.2 does not apply. The other rules for inserting
optional blanks around values in list-directed output allow the
processor to insert optional leading and trailing blanks around a
list item. The standard does not specify when optional blanks are
written; therefore, when two adjacent list items (the values
thereof) are written to an output record, and only one of them was
written by list-directed input/output, the standard does not
specify whether or not any optional blanks appear between those
values in the output record.
4) It is processor dependent whether or not a separator appears
between two such character sequences. See answer 3.
5) The result should be "xyz5xyz", that is, the recursive i/o to the
internal file does not affect whether the character sequences being
written by the outer data transfer statement are considered
adjacent.
6) No, if an outer data transfer is to an internal file, then a
recursive i/o operation to a different internal file or an external
file does not affect whether the character sequences are considered
adjacent.
NOTE TO J3:
In Fortran 2008, recursive i/o operations to a different external unit
are allowed and these also ought not to affect whether the character
sequences written by the outer data transfer statement are considered
to be adjacent. The edit to F2003 below will produce that result when
applied to the (draft) F2008.
EDITS:
[241:5] In Section 10.9.2, add the following to the end of the
first paragraph:
"Two undelimited character sequences are considered adjacent when
both were written using list-directed input/output, no intervening
data transfer or input/output file positioning operations on that
unit occurred, and both were written either by a single data
transfer statement, or during the execution of a parent data
transfer statement along with its child data transfer statements."
SUBMITTED BY: Rob James
HISTORY: 05-140 m171 F03/0049 Submitted
05-140r1 m171 Passed by J3 meeting
05-170 m172 Failed J3 letter ballot #11
06-367r1 m178 Passed by J3 meeting
07-272 m181 Passed as changed by J3 letter ballot #13
08-155 m184 Failed WG5 ballot #4 N1711-N1721
08-182r1 m184 Revised answer - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0071
TITLE: Subroutine/function ambiguity in generics
KEYWORDS: subroutine, generic, implicit
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Q1. Is the following generic allowed?
interface q
subroutine qr(f)
implicit real(f)
external f
end subroutine
subroutine qc(f)
implicit complex(f)
external f
end subroutine
end interface q
The uncertainly arises because it is not established
whether F is a subroutine or a function. If either F
were a subroutine, then it would be clear that the
generic was disallowed. One might be able to use this
to deduce that both Fs must be functions. This seems
like an obscure deduction to demand of the compiler.
Q2. Consider the following "obviously" allowed generic
module m
interface q
subroutine qr(f)
real, external :: f
end subroutine
subroutine qc(f)
complex, external :: f
end subroutine
end interface q
end module m
Is the following main program valid?
program main
use m
external ff
call q(ff)
end
Again, the problem is that it is unclear whether or not
ff is a function or subroutine. If it is a subroutine,
then the call is ambiguous. One might thus deduce that
ff must be a function, and therefore of type real,
but this seems like an obscure deduction to demand of
the compiler.
ANSWER:
1. The program fragment is not conforming. A generic interface is
required to be nonambiguous. This is a similar situation to the
declaration of an external procedure in a module, where a procedure
that is a function is required to have its type and type parameters
explicitly declared. An edit is provided to require this for
specific procedures in a generic interface.
2. The main program is conforming. As remarked, at the call site the
procedure is known to be either a subroutine or a function. Since
the generic does not allow a subroutine as an argument, it must
therefore be a function. Implicit typing means that ff is real so
qr is called. (The generic cannot have a specific that
accepts a subroutine as an argument, as that would violate the
requirements in 16.2.3.)
EDITS:
[261:3] In 12.3.2.1 Interface block,
immediately after "A generic interface is always explicit.",
append new sentence to paragraph
"If a specific procedure in a generic interface has a function
dummy argument, that argument shall have its type and type
parameters explicitly declared in the specific interface."
{I.e. if you just say EXTERNAL dummy, you must mean a subroutine.}
SUBMITTED BY: Richard Maine
HISTORY: 05-265 m174 F03/0071 Submitted
08-189r1 m184 Answer provided - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0073
TITLE: C interop of dummy procedures
KEYWORDS: Interoperability, dummy procedures
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
QUESTION:
Is the following interface interoperable, and if yes, what is the
interoperable C prototype?
subroutine my_sub(my_fun) bind(c, name="My_Proc")
interface
function my_fun(x) bind(c)
use iso_c_binding
integer(c_int) :: my_fun
real(c_double), value :: x
end function
end interface
end subroutine
ANSWER:
Yes, this interface is interoperable with the following prototype:
void My_Proc(int (*his_fun)(double));
Its formal parameter is of a pointer type, and the referenced type is
a function that is interoperable with my_fun, thus satisfying the
requirements in item 5 in the list in subclause 15.2.6.
EDITS:
None:
SUBMITTED BY: Aleksandar Donev
HISTORY: 06-102 m175 F03/0073 Submitted
08-188r1 m184 Answer proposed - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0074
TITLE: Type mismatch for C character arguments
KEYWORDS: Interoperability, dummy procedures
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Is the following conforming if the C character kind (C_CHAR) is not
the same as the default character kind (KIND('A'))?
use iso_c_binding
Interface
Subroutine sub(string) Bind(C)
import C_Char
Character(Kind=C_Char) :: string(*)
End Subroutine
End Interface
Character(Kind=C_Char,Len=10) :: string
Call sub(string)
The second and 3rd paras of 12.4.1.2 do not treat C character kind the
same as default character kind, and seem to require matching type
parameter values between the actual and dummy. This makes Note 15.23
nonconforming if C_CHAR is not the same as default character kind, and
is also not in sync with 270:25-26.
ANSWER:
Yes, the program fragment is standard-conforming. An edit is provided
to correct the oversight in 12.4.1.2.
EDITS:
[269:3,5,8] After each "of type default character",
Insert "or of type character with the C character kind (15.1)",
Thrice.
SUBMITTED BY: Aleksandar Donev
HISTORY: 06-105 m175 F03/0074 Submitted
08-190r1 m184 Revised answer - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0075
TITLE: C interop of derived types with array components
KEYWORDS: Interoperability, dummy procedures
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Is the following C struct:
typedef struct
{
float x[5];
} array;
interoperable with this Fortran type:
type, bind(c) :: array
real(c_float) :: x(3)
end type
ANSWER:
No. According to the words in 15.2.3, the answer is yes, since only
interoperability of the types of the C and Fortran components is
required. This is, however, an oversight. An edit is provided to
correct this.
EDITS:
In the first sentence of the first paragraph after NOTE 15.12 in
subclause 15.2.3 [04-007:398:11-12], replace "have types and type
parameters that are interoperable with the types of the corresponding
components of the struct type" with "would interoperate with
corresponding components of the C struct type as described in 15.2.4 and
15.2.5 if the components were variables".
SUBMITTED BY: Aleksandar Donev
HISTORY: 06-106 m175 F03/0075 Submitted
08-191r1 m184 Revised answer - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0076
TITLE: Scope of Fortran names of procedures with binding labels
KEYWORDS: Interoperability, dummy procedures
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
QUESTION:
Is the following conforming:
module A
interface
subroutine CProc() bind(C,name="AnExternalCProcedure")
end subroutine
end interface
end module
module B
interface
subroutine CSub() bind(C,name="AnExternalCProcedure")
end subroutine
end interface
end module
ANSWER:
No, the fragment is not conforming. The name of an external procedure is
a global entity and is required to be unique. That is, the external C
procedure AnExternalCProcedure, must be given a unique Fortran name
inside a Fortran program.
EDITS:
None.
SUBMITTED BY: Aleksandar Donev
HISTORY: 06-107 m175 F03/0076 Submitted
08-187 m184 Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0077
TITLE: LBOUND of array structure component
KEYWORDS: LBOUND, lower bounds, bounds, structure component, array
sections
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Given the declarations
TYPE t
REAL x
REAL y(-5:5)
END TYPE
TYPE(t) z(10:20)
What is the result of the following LBOUND references:
LBOUND(z(10)%y)
LBOUND(z%x)
The confusion arises because the existing definition of LBOUND uses
the undefined term "array structure component" in determining whether
to return the lower bound in the <array-spec> or 1. It seems clear
that Z(10)%Y must be an array structure component (so the answer ought
to be -5) but it is not clear whether Z%X is one and therefore whether
the result of that LBOUND ought to be 1 or 10.
ANSWER:
Yes, the result of the first LBOUND is indeed -5.
The result of the second LBOUND is 1.
Clarifying edits are provided.
The description of the intrinsic function UBOUND suffers from the same
flaw, and the edits provided fix that function as well.
EDITS:
To avoid the undefined term, or any long phrase, the edit changes the
definition of "whole array" to include the case of a whole array
component of a structure.
[107:2-3] Replace the existing definition which is
"A whole array is a named array, which may be either a named
constant (5.1.2.10, 5.2.9) or a variable; no subscript list is
appended to the name."
with
"A <<whole array>> is a named array or a structure component whose
final <part-ref> is an array component name; no subscript list is
appended."
{Make "whole array" include the whole array component case.}
[107:7-8] Replace "whole array name" with "whole array designator",
twice.
[326:8] After "a whole array" delete "or array structure component".
{No longer need kludgy wording in LBOUND.}
[358:6-7] After "a whole array" delete "or array structure component".
{No longer need kludgy wording in UBOUND.}
[436:36] After "named array" insert
"or array component of a structure, with no subscript list."
{Fix the glossary.}
SUBMITTED BY: Aleksandar Donev
HISTORY: 06-118 m175 F03/0077 Submitted
08-174 m184 Revised with edits
08-174r1 m184 Fixed typo - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0081
TITLE: F edit descriptor with field width 0
KEYWORDS: Data edit descriptors, F edit descriptor, field width
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
QUESTION:
Does the Fortran 2003 standard allow the output field produced by an F
edit descriptor with a field width w whose value is zero for a real
value whose magnitude is less than one to include an optional leading
zero?
For example, is the PRINT statement
PRINT '(F0.2)', 0.01
allowed to write "0.01"?
ANSWER:
No. This is clear from Section 10.6.1 of the Fortran 2003 standard,
item (6).
EDITS: None.
SUBMITTED BY: Michael Ingrassia
HISTORY: 06-127 m175 F03/0081 Submitted
08-175 m184 Editorial revision - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0082
TITLE: VALUE in place of INTENT for pure procedure dummy arguments
KEYWORDS: VALUE, INTENT, PURE
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
QUESTION:
C1266 requires all nonpointer dummy arguments of a pure function to be
data objects that have INTENT(IN). C1267 requires all dummy arguments
of a pure subroutine to have specified intents.
Was it intended that VALUE not be allowed in place of INTENT(IN), that
is, was it intended that if a dummy argument of a pure procedure has
the VALUE attribute, it is nonetheless also required to have the
INTENT(IN) attribute explicitly specified?
ANSWER:
The possible extension of the VALUE attribute to allow omission of the
INTENT(IN) attribute in the specific case of pure procedures was not
considered during the development of Fortran 2003. However, the
standard is consistent and not in error, and so this restriction
should remain.
EDITS:
None.
SUBMITTED BY: Van Snyder
HISTORY: 06-153 m176 F03/0082 Submitted, fix edit, needs more
08-176 m184 Reversed answer + revised alternative edits
Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0087
TITLE: Entry names as dummy procedure arguments
KEYWORDS: Entry names, dummy procedure arguments
DEFECT TYPE: Interpretation
STATUS: Passed by J3 meeting
QUESTION:
Does the following subprogram fragment conflict with the 2003 Fortran
standard? If so, was the conflict intended?
entry A ( X )
interface
subroutine X ( A )
abstract interface
subroutine I ( ... )
...
end subroutine I
end interface
procedure (I) A
end subroutine X
end interface
...
It seems that constraint C1255 in subclause 12.5.2.4 [283:10-12]
prohibits the entry name A to appear in the PROCEDURE statement in
the interface body. There shouldn't be a problem, however, since
the PROCEDURE statement is in a different scoping unit.
ANSWER:
No, this program fragment conforms to the 2003 Fortran standard.
EDITS:
None
NOTE:
C1255 is pointless because Clause 16 applies. It could
fruitfully be removed from a future revision of the Fortran standard.
SUBMITTED BY: Van Snyder
HISTORY: 07-105 m179 Submitted F03/0087
07-105 m179 Passed by J3 meeting
07-272 m181 Failed J3 letter ballot #13 07-250r1
08-192r1 m184 Revised answer - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0098
TITLE: Does allocate with source= define subcomponents?
KEYWORDS: allocate, source, define
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Was it intended that an allocate with a source= clause define
subcomponents?
Bullet 11 on 422 says "Successful execution of an ALLOCATE statement
...causes the subcomponent to become undefined."
ANSWER:
An Allocate with a SOURCE= specifier was intended to define
subcomponents.
In fact, none of the lists in clause 16 account for a SOURCE=
specifier. Edits are supplied to clarify this.
EDITS:
[113:21] At the end of the last sentence in 6.3.1.1 insert
"unless the SOURCE= specifier appears and the corresponding
component of the <source-expr> is allocated".
[421:27] 16.5.5, list item 19, after "Allocation", insert
", except by an ALLOCATE statement with a SOURCE= specifier,"
[421:28+] 16.5.5, insert new list item after (19)
"(19a) Successful execution of an ALLOCATE statement with a SOURCE=
specifier causes a subobject of the allocated object to
become defined if the corresponding subobject of the SOURCE=
expression is defined."
[422:41-42] 16.5.6, list item (11), replace list item with
"Successful allocation of an ALLOCATE statement with no SOURCE=
specifier causes a subcomponent of an allocated object to become
undefined if default initialization has not been specified for
that subcomponent."
[422:43+] 16.5.6, add a new list item after (11),
"(11a) Successful execution of an ALLOCATE statement with a SOURCE=
specifier causes a subobject of the allocated object to
become undefined if the corresponding subobject of the
SOURCE= expression is undefined."
SUBMITTED BY: Dick Hendrickson
HISTORY: 07-268 m181 F03/0098 Submitted
07-268r2 m181 Passed by J3 meeting
07-279 m182 Passed as changed by J3 LB #14 07-321
08-155 m184 Failed WG5 ballot #4 N1711-N1721
08-183 m184 Revised edits - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0112
TITLE: attributes allowed for dummy arguments in defined assignments
KEYWORDS: defined assignment, dummy argument, attributes
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
DISCUSSION:
It seems the standard is quite loose in allowing various attributes
declared for the dummy arguments used in a defined assignment
(7.4.1.4). In particular, attributes such as POINTER and ALLOCATABLE
can be declared for dummy arguments in the defined assignment.
However the interpretations on their declarations need to be
clarified.
Consider the follow subroutines (assuming a derived type DT already
defined)
1. POINTER/ALLOCATABLE on the second dummy argument
interface ASSIGNMENT (=)
subroutine defAssgn1 (dt1, dt2)
type(DT), intent(out) :: dt1
type(DT), POINTER, intent(in) :: dt2
end subroutine
end interface
In 12.3.2.1.2 [263:10-12], the standard says the following
"A defined assignment is treated as a reference to the subroutine,
with the left-hand side as the first argument and the right-hand
side enclosed in parentheses as the second argument."
This statement seems to prohibit the use of subroutine defAssgn1
for defined assignment since a pointer enclosed in parentheses
refers to its associated target not the pointer itself, as
indicated by rules in 7.1.4.1 [123:39-124:3].
2. POINTER/ALLOCATABLE on the first dummy argument
interface ASSIGNMENT (=)
subroutine defAssgn2 (dt1, dt2)
type(DT), POINTER, intent(out) :: dt1
type(DT), intent(in) :: dt2
end subroutine
end interface
There are no rules in the standard disallow this declaration.
However the use of POINTER/ALLOCATABLE attributes on the first
dummy argument is very doubtful. Since POINTER/ALLOCATABLE
attributes don't disambiguate generic declarations(16.2.3), their
use will prevent the normal declarations of defined assignments,
wherein dt1 is declared without POINTER or ALLOCATABLE attribute.
QUESTIONS:
1. Are POINTER and ALLOCATABLE attributes allowed for the second
dummy argument in defined assignment?
2. Are POINTER and ALLOCATABLE attributes allowed for the first
dummy argument in defined assignment?
ANSWER:
Yes to both questions. The standard places very few restrictions on
the arguments to defined assignment subroutines: [263:6...]
Each of these subroutines shall have exactly two dummy arguments.
Each argument shall be nonoptional. The first argument shall have
INTENT (OUT) or INTENT (INOUT) and the second argument shall have
INTENT (IN). ...
Preventing the first argument from having the POINTER
attribute violates F90. Such a restriction for the second argument
has no effect since the right argument is treated as an expression
enclosed in parentheses which would have neither attribute but it
does no harm. An edit is provided.
EDITS:
In section 12.3.2.1.2 of 04-007, second paragraph, at the end of the
third sentence [263:8], after "INTENT (IN)", insert "and shall not
have the ALLOCATABLE attribute".
SUBMITTED BY: Jim Xia
HISTORY: 08-120 m183 F03/0112 Submitted
08-120r1 m183 Create answer
08-120r2 m183 Passed by J3 meeting
08-163 m184 Failed J3 letter ballot 08-141
08-186r1 m184 Another answer - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
NUMBER: F03/0117
TITLE: STOP executed via function in input/output list
KEYWORDS: STOP
DEFECT TYPE: Erratum
STATUS: Passed by J3 meeting
QUESTION:
Interpretation F90/000209 considered the question
Section 9.7. May a function referenced in an I/O statement
execute a STOP or PAUSE statement? If STOP statements are
permitted, what is the state of the file at the end of
execution?
The answer (w.r.t. STOP), included in F95 corrigendum 2, replied
No, a STOP statement may not be executed in this situation.
Executing a STOP statement causes normal termination of
execution, which closes all files (9.3.5), and this is equivalent
to executing a CLOSE statement, which is prohibited by 9.7. A
clarifying edit is supplied.
This answer was reasonable for Fortran 90/95, but the reasoning is
defective when applied to Fortran 2003. Fortran 2003 allows execution
of a CLOSE statement for any external file during the execution of an
internal i/o statement (so-called "recursive i/o"). It seems that
this consideration was overlooked for Fortran 2003.
However, on further consideration of the reasoning behind this answer,
it seems unhelpful to rule out STOP, which is often used for user
signalling of error conditions, during i/o operations. For one thing,
if the data transfer statement being executed is READ, the question
about file state has a very straightforward answer. It might also be
considered unhelpful in the WRITE case for STOP to cause the user's
entire file system to be potentially reformatted instead of just
making the contents of the relevant file undefined.
Furthermore, the user who wants to signal an error can cause error
termination via one of the "approved" methods such as DEALLOCATE of an
unallocated array. It seems less than unhelpful to force the user to
use such a circumlocution simply for standards conformance, and the
question about file state can equally be asked of this situation.
Q1. Is execution of a STOP statement during internal i/o allowed?
Q2. Is execution of a STOP statement during a READ statement allowed?
Q3. Is execution of a STOP statement during a WRITE statement allowed?
Q4. What is the effect on the file state of executing the following
code fragment during a WRITE statement to an external file:
REAL,ALLOCATABLE :: array(:)
DEALLOCATE(array)
(And if the answer to Q3 is yes, does a STOP statement have the
same effect.)
ANSWER:
The answer to the first three questions is yes, this should have been
allowed. An edit is provided to correct the standard.
The answer to Q4 is that the effects on the file currently being
written by that WRITE statement are not standardised. (This was, in
fact, the situation before the adoption of the previous interp
answer.) A clarifying edit is provided to indicate that the contents
of the file become undefined.
EDITS:
[195:23+]
In 9.5.3 "Execution of a data transfer input/output statement",
immediately before Note 9.38 insert a new paragraph
"If execution of the program is terminated during execution of a
WRITE or PRINT statement, the contents of the file become
undefined."
Delete [219:30] the last paragraph of 9.11 which currently reads
"A STOP statement shall not be executed during execution of an
input/output statement."
SUBMITTED BY: Malcolm Cohen
HISTORY: 08-173 m184 F03/0117 Submitted - Passed by J3 meeting
08-213 m185 In J3 letter ballot #17
----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20080622/dd53fc7b/attachment-0001.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 08-213 LB17 due 25-Jul-2008.txt
Url: http://j3-fortran.org/pipermail/j3/attachments/20080622/dd53fc7b/attachment-0001.txt
More information about the J3
mailing list