(j3.2006) J3 Fortran interp letter ballot #22 - due 19-Nov-2010
Fri Oct 15 20:22:18 EDT 2010
On Thu, 2010-10-14 at 17:07 -0700, Whitlock, Stan wrote:
> The following Fortran interpretations are being balloted:
> Yes No Number Title
-C- --- F03/0030 IEEE divide by zero
Change "not true" to "false" because "not true"
includes "undefined". This leaves the program non-conforming
(presumably because the processor is defective) if the result
After [403:10-11] insert "14.3p1, second bullet"
After [462:24+] insert "A.2p1"
-C- --- F03/0048 Control edit descriptors in UDDTIO
Change reference in the question to 126.96.36.199p26
In edits for [227:15], replace "section 188.8.131.52, in"
by "184.108.40.206p25," or insert ", 25th paragraph," after "220.127.116.11"
In edits for [227:17] and [227:18], replace "section 18.104.22.168"
by "22.214.171.124p26" or insert ", 26th paragraph" after "126.96.36.199"
In edits for [487:28] maybe replace "section C.6.2, first
paragraph" by "C.6.2p1".
-Y- --- F03/0085 Finalizing targets of pointer or allocatable
-Y- --- F03/0091 Array components cannot depend on length type
-C- --- F03/0096 Can a read statement change the unit value?
In the ANSWER, change "n the specifier" to "in the specifier".
-C- --- F03/0105 SIZE= specifier and UDDTIO
In the Discussion, change "188.8.131.52 [191:21-26]" to
"184.108.40.206 [216:32-36]". Change "using list-directed" to
"using a list-directed"
-C- --- F03/0110 Error in field width for special cases of signed
Change the title here to "Restoring dropped restriction on
-C- --- F03/0121 Precise FP semantics of the REAL intrinsic
This question keeps coming up, and the committees keep
avoiding the most useful answer, i.e., the one the submitter
(that is, a real user with a real problem) always asks for.
Although the answer correctly interprets the standard, the
result is to force the programmer to use a mysterious kludge.
Hopefully, some future revision of the standard actually will
require REAL with a KIND argument to produce a result of the
specified kind, not one of whatever representation the
processor happens to find handy.
-C- --- F03/0123 Implicit typing in derived types
Does this beg for another interpretation request with
IMPLICIT NONE in the main program?
--- -N- F03/0124 definition is poorly defined
The answer implied by the edits is too restrictive. It should
be something like
"When a component of a structure of numeric sequence type or
character sequence type becomes defined as a result of
partially associated objects becoming defined, associated
components of the same type that are components of an object
of different type do not become undefined." (This is ugly and
will need some polishing, but you get the idea.)
-Y- --- F03/0128 Subobjects in namelist output
-Y- --- F08/0006 generic resolution with banned argument
-Y- --- F08/0040 MOVE_ALLOC for coarrays
--- -N- F08/0041 Segment ordering rules
"is defined" is a static concept. The requirement should
always have been "becomes defined". Therefore the edit should
be to replace "variable is defined" to "variable becomes
defined or undefined" -- or do we need another interp to
-C- --- F08/0042 SOURCE= questions
To avoid future questions of the type "how many times is ...
evaluated?" can we specify that the values of specifiers are
considered to be actual arguments to subroutines, so that the
execution semantics of CALL statements, i.e., the actual
arguments are evaluated before the invocation, apply
-Y- --- F08/0043 Executing a type-bound procedure on a coindexed
-Y- --- F08/0044 Resolving the type of a coarray or coindexed object
-Y- --- F08/0045 constraints on entities of type LOCK_TYPE
-Y- --- F08/0046 VALUE attribute restrictions
-Y- --- F08/0047 public generic with same name as private type
-Y- --- F08/0048 Sequence association for coarrays
-Y- --- F08-0049 ELEMENTAL functions with nonconstant type
More information about the J3