(j3.2006) deallocating pointer function results

[Malcolm Cohen]

<<<
Because a function reference is not allowed as an
/allocate-object/ in a DEALLOCATE statement, a dummy argument
corresponding to an actual argument that is a function reference
is not allowed as an /allocate-object/ in a DEALLOCATE statement.
>>>

I agree with that.  Moreover, the DEALLOCATE sets the pointer association 
status of the dummy argument (and thus the actual) to disassociated, which 
clearly cannot be done unless it is a "real" pointer variable.

<<<
(I doubt that any existing implementation catches this error.)
>>>

You mean:

Runtime Error: junk.f90, line 16: Dummy argument P is associated with an 
expression - cannot deallocate
Program terminated by fatal error

DEALLOCATE is not different in this respect from ALLOCATE, NULLIFY and 
pointer assignment: they are all modifying the pointer association status of 
the actual argument, which being an expression, cannot be modified.

<<<
I think that the behavior that results from the statement
marked (3) is intended not to be permitted.
>>>

Without wishing to state a position on that...

<<<
  I base my
conclusion on a somewhat strained reading of Subclause 12.5.2.13,
paragraph 1, which states

       While an entity is associated with a dummy argument,
       the following restrictions hold.

           (1) Action that affects the allocation status of
               the entity or a subobject thereof shall be
               taken through the dummy argument.

One issue concerns the meaning of the phrase "the allocation
status".  I am assuming that it means "the allocation status or
pointer association status".
>>>

It most emphatically does NOT.

<<<
  In all other cases where both the
allocation status and the pointer allocation status are meant,
they are both mentioned.
>>>

Of course.

<<<
  A reason to believe that both are
intended here is that the text in the Fortran 90 standard
(Subclause 12.5.2.9 of the Fortran 90 standard) from which the
quoted text was derived was described in a way that included
both cases.
>>>

Fortran 90 did not have ALLOCATABLE dummy arguments in the first place.

<<<
The dummy argument is not used in the DEALLOCATE statement; a
local pointer variable is used in its place.  I assume that the
deallocation is therefore not done "through" the dummy argument.
An argument can be made against my assumption based on
Subclause 5.3.10, paragraph 2.  It states

       The INTENT(IN) attribute for a pointer dummy argument
       specifies that during the invocation and execution of
       the procedure its association shall not be changed
       except that it may become undefined if the target is
       deallocated other than through the pointer (16.5.2.5).
>>>

Right.

<<<
If the "allocation status" of the pointer may be changed only
through the dummy argument, then the last part of that clause
is unnecessary.
>>>

Once more with feeling: a pointer ***does not have an allocation status***. 
Not ever, seeing as how no entity can possess both the POINTER and 
ALLOCATABLE attributes.

>I would like to know if anyone disagrees with my conclusions.

Without wishing to commit to whether (3) is intended to be valid or not, the 
argument presented does not hold water.  Off the top of my head, without 
carefully checking, it might or might not be valid with the existing text, 
but it is certainly plausible that it might be intended to be valid, on the 
grounds that the program is not actually modifying the bits of the internal 
representation of the pointer in question.

(I would guess that the existing text does not permit (3) simply because 
there is no equivalent text corresponding to what we wrote for INTENT(IN); 
but again, that is without any careful consideration.  There certainly are 
arguments against allowing (3) as well as arguments for permitting it.)

Cheers,
-- 
............................Malcolm (on holiday).