Jim Riley wrote:
> Would set X(51) to 123., but its effect on I(51) would be undefined.
and Bill Long replied:
> Actually, the *effect* on I(51) is well defined by the standard. I(51)
> becomes undefined.
Of course, to fully appreciate Bill's (accurate) comment, you need
to understand how the standard defines "undefined". I'm tempted
to add a smiley...except that the question is real and nontrivial.
The question of what the meaning of "is" is comes up much less
often, though I almost hate to admit that I've actually had to
make a point about it before (where someone used "is" instead of
a form of "shall" to express a requirement). :-(
To other matters..note that the cases mentioned are very simple ones
because of their homogeneity. You don't have to get very complicated
at all before valid implementation strategies get severely
constrained. The non-obvious ones start needing to get very messy.
Consider (assume implicit typing)
subroutine sub1
common /com/ x(3),i,y,j
save /com/
y = 123.4
j = 567
...
end
subroutine sub2
common /com/ i(3),x,y,j
save /com/
...
end
The assignments to y and j in sub1 will cause y and j in
sub2 to be defined (and being defined is a much less tricky
concept in the standard than being undefined is).
It is certainly posible in theory for a compiler to implement this
with separate storage areas for reals and integers. Whether it is
practical is a different matter - I'd guess not.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|