(j3.2006) (DE)ALLOCATE with STAT= question

[Malcolm Cohen]

Bill Long claimed
>Standard says necessarily.

I do not agree.

The standard says
  "If any other error condition occurs"
and this is also true.

So we have two "if"s that are true.  That means that STAT= is defined with the 
value of STAT_STOPPED_IMAGE, and that it is also defined with a value different 
from STAT_STOPPED_IMAGE.

So at best the standard is contradictory ... I was actually trying not to go 
there, but maybe I tried too hard.  Note that the second sentence does not say 
"Otherwise, if", which is the wording we use if we mean "otherwise, if".

Given that under a strict reading of the actual wording the standard is 
contradictory, the program is not conforming (no unambiguous interpretation is 
established).

(I already gave this reasoning in my previous message, but perhaps not clearly 
enough because saying that the program is "not conforming" is generally 
unhelpful - and in this case it leads to the conclusion that the compiler can do 
whatever it likes, i.e. it is not required it to set it to STAT_STOPPED_IMAGE or 
to set it to any different value.)

Now I did not think we meant this to be an "otherwise, if" ... because I do not 
recall the question even coming up in discussion.  (The ALLOCATE/DEALLOCATE 
statements are nominally owned by "DATA" subgroup, so if there was a discussion 
I certainly should have remembered it!  This is the first I've heard of any 
suggestion that our previous unordered model for ALLOCATE/DEALLOCATE was being 
altered.)

If you think that it needs to be an "otherwise, if" let's have an interp to fix 
the wording.  Well, given the wording is ambiguous already, we should do the 
interp anyway, regardless of which way we are going to clarify it.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.