J3/11-150
To: J3
From: Malcolm Cohen
Subject: Definition is poorly worded
Date: 2011 February 17
----------------------------------------------------------------------
NUMBER: F03/0124
TITLE: Definition is poorly defined
KEYWORDS: definition
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress
QUESTION:
Consider the program:
PROGRAM example1
TYPE T1
SEQUENCE
INTEGER I, J
END TYPE
TYPE T2
SEQUENCE
INTEGER I, J
END TYPE
TYPE(T1) X
TYPE(T2) Y
EQUIVALENCE (X, Y)
X%I = 1
X%J = 2
PRINT *, X, Y
END
Q1. Is this program standard-conforming, and if so, what does it
print?
According to items (1) and (12) of 16.6.5, the assignment to X%I
causes both X%I and Y%I to become defined.
Similarly, the assignment to X%J causes both X%J and Y%J to become
defined.
Then, according to item (15) of 16.6.5, both X and Y become defined.
However, according to 4.5.2.4, X and Y are types with different names,
and therefore are of different type, thus according to 16.6.6 item (1)
when X becomes defined Y becomes undefined, and vice versa. This
appears to be a contradiction.
Furthermore, consider
PROGRAM example2
TYPE t
INTEGER a,b
END TYPE
TYPE(t),TARGET :: x
INTEGER,POINTER :: p
x = t(1,2)
p => x
p = 33
PRINT *,x
END PROGRAM
According to the quoted text, the assignment to P is defining a
variable of type INTEGER, and one that is associated (partially, via
pointer association) with a variable of type T. That would seem to
make X undefined according to item (1) of 16.6.6.
Q2. Is example2 intended to be standard-conforming?
Finally, consider
MODULE ugly1
TYPE t1
INTEGER a,b
END TYPE
INTEGER w,z
TYPE(t1) x
COMMON/c/w,x,z
END MODULE
MODULE ugly2
TYPE t2
INTEGER c,d
END TYPE
TYPE(t2) y1,y2
COMMON/c/y1,y2
END MODULE
BLOCK DATA
COMON/c/i(4)
DATA i/1,2,3,4/
END BLOCK DATA
PROGRAM example3
USE ugly1
USE ugly2
! At this point c is 1,2,3,4.
y1 = t2(66,-6)
PRINT *,w ! Is this ok?
w = 0
PRINT *,y1 ! And is this ok?
END PROGRAM
This is similar to example1, except that we are defining a whole
variable of sequence type at once, not by partial definition.
Q3. Is example3 standard-conforming?
ANSWER:
A1. The program was intended to be standard-conforming.
An edit is supplied to remove the apparent contradiction.
The program should print something like " 1 2 1 2".
A2. Yes, example2 is intended to be standard-conforming.
An edit is supplied to remove the problem.
A3. Yes, example3 is intended to be standard-conforming.
An edit is supplied to remove the problem.
DISCUSSION:
The only interesting case of variable definition causing an associated
variable to become undefined is using the old FORTRAN 77 data types;
all the other intrinsic types are not permitted to be associated with
variables of different type.
We only need to get the scalar intrinsic case right, as the array and
derived type cases then follow automatically from the definitions in
16.6.1.
EDITS:
[455:4-10] Replace 16.6.6 item (1) entirely:
"(1) When a scalar variable of intrinsic type becomes defined, all
totally associated variables of different type become
undefined.
(1a) When a double precision scalar variable becomes defined, all
partially associated scalar variables become undefined.
(1b) When a scalar variable becomes defined, all partially
associated double precision variables become undefined."
[455:36] Change "(1)" to "(1)-(1b)".
{Fix reference.}
SUBMITTED BY: Robert Corbett (via Van Snyder via Dan Nagle)
HISTORY: 08-269 m185 F03/0124 submitted
10-245 m193 Draft answer - Passed by J3 meeting
11-129 m194 Failed J3 letter ballot #22 10-254
11-nnn m194 Revised answer
----------------------------------------------------------------------