(j3.2006) Alleged contradiction

Malcolm Cohen malcolm
Sun Jan 17 19:32:26 EST 2010


Robert Corbett wrote:
> Malcolm Cohen wrote:
>> Allocation status is for allocatable variables.
>> *Association* status is for pointers.
...
> My understanding of the intended meaning of the phrase "allocation
> status" in item (1) of Section 12.5.2.13 differs from yours.

And from the rest of the standard.

I see that this would benefit from allocation status being properly indexed - 
somehow I missed that in the great "defined term" reorganisation.

If you go back to the F2003 standard, which you might as well since the text 
(though not the indexing) is unchanged, you will see that "allocation status" is 
a defined term that only applies to allocatables.

If you read through the F2008 standard, you will find that the only normative 
text that gives meaning to "allocation status" is the stuff in c06 that does it 
for allocatables.  That is admittedly less friendly that before, but there was 
certainly no deliberate decision to break the standard on this!  And since it 
isn't listed in c01 as a change from F2003, it is clear that the F2003 
interpretation ("allocation status is for allocatables only") is the one that is 
meant.

>  My
> understanding of the phrase in that context is that it applies to
> any allocated object.

You are incorrect, as explained above.

Furthermore, if "allocatable" meant "allocatable or pointer", we wouldn't be 
saying "allocatable or pointer" all over the standard.

> The comments in Note 12.34 support my
> interpretation.

The comments in Note 12.34 are poorly written so don't support *ANYONE*.

>  There are no allocatable variables in the example
> given in the note.  The variable A in the example is a pointer
> variable, not an allocatable variable.  Under my interpretation,
> the sentence
>
>      Similarly,
>
>      DEALLOCATE (A)
>
>      would not be allowed because this affects the allocation
>      of B without using B.
>
> makes sense.

No it does not, since B is (in the example) neither pointer nor allocatable.

Furthermore it isn't using "allocation status".

  Under the interpretation that the phrase "allocation
> status" in this context applies only to allocatable variables,
> that sentence makes no sense.

(a) it isn't using the term anyway
(b) it doesn't make sense anyway since even with the wrong interpretation of 
"allocation status", B ***DOES NOT HAVE ONE***.

Note 12.34 is poorly written, but it is obviously talking about the underlying 
memory allocation of B, not anything to do with Fortran itself.

>  Under that interpretation, there is
> no prohibition against deallocating a pointer variable that is
> argument associated with a variable dummy argument.

Deallocating a pointer causes the target to become undefined, which is 
prohibited by the second sentence of p1.

>  If the
> standard included a provision that such a variable dummy argument
> became undefined when the pointer was deallocated,

I don't think there is any doubt that deallocating a pointer causes the target 
to become undefined.

(This can be deduced from the normative text, but requires far more effort than 
it should.  It would be nice to clean that up sometime.)

Thus the effect on the dummy argument is caught by 16.6.6 number 9, since the 
dummy argument is associated with the target.

> I might believe
> that the intent was to allow such deallocations, but there is no
> such provision in Section 16.6.6.

See explanation above.

> As was discussed on this alias last month, the final sentence of
> Note 12.34 is not supported by the text of the standard.  That
> flaw does weaken arguments based on the other content of the note.
> Nonetheless, I hope no one supposes that the standard intends to
> allow a pointer variable to be deallocated while the pointer is
> argument associated with a variable dummy argument.

No-one is arguing that strawman you just constructed, assuming you are using 
"variable" to mean "nonpointer variable".

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




More information about the J3 mailing list