From maine@altair.dfrc.nasa.gov Fri Oct 6 23:30:44 1995 Received: from altair.dfrc.nasa.gov (altair.dfrc.nasa.gov [130.134.34.72]) by dkuug.dk (8.6.12/8.6.12) with SMTP id XAA21907 for ; Fri, 6 Oct 1995 23:30:40 +0100 Received: by altair.dfrc.nasa.gov (5.0/SMI-SVR4) id AA07514; Fri, 6 Oct 1995 15:32:26 +0800 Date: Fri, 6 Oct 1995 15:32:26 +0800 Message-Id: <9510062232.AA07514@altair.dfrc.nasa.gov> From: Richard Maine To: sc22wg5@dkuug.dk In-Reply-To: <199510061717.SAA14177@dkuug.dk> (hirchert@ncsa.uiuc.edu) Subject: Re: (SC22WG5.892) Interp 179 - DO variable with POINTER attribute content-length: 1991 Kurt said: > DO P=1,10 > IF (P==6) P=>K ... > If this program is not prohibited,... By my reading it is already prohibitted. > 3. We could allow the form but disallow the change in identity. (In other > words disallow the pointer assignment inside the DO loop in our example.) This appears to be what the standard already does. It disallows any redefinition of the DO variable within the loop. The pointer assignment redefines the DO variable P. Anyway, that's how I interpreted Malcolm's comment, and I decided I agree with it. The standard already appears to disallow this reassignment. > Although this would solve the problem, I find it a less acceptable > solution because it is inconsistent with how we handled the problem > in the "related program". (We didn't just object to the assignment to IP, > we objected to the use of IA(IP) in the first place.) I don't find this sufficient reason to retroactively declare formerly legal code to now be illegal. If this consistency were important, I'd say it was better argument for the opposite change - allowing array elements. Note that we allow IA(IP) as a subroutine argument, even if IP is changed within the subroutine. So this retroactive change isn't suddenly going to make things seem consistent. I'd say that users would be more surprised by the *IN*consistency introduced, namely that pointers can be used everywhere except for DO variables. Considering the trivial case where the pointer is not reassigned within the DO loop, it seems that we are going to get users asking "what's wrong with this?" > b. We still would need an "extra" prohibit against deallocating the > DO variable during the execution of the loop. That consitutes an undefinition of the DO variable, which is already prohibited. Note that the DO variable is P, not its target. P does happen to be an alias for its target, but I don't see how that changes anything. -- Richard Maine maine@altair.dfrc.nasa.gov