(j3.2006) deallocating pointer function results
Wed Nov 4 01:31:49 EST 2015
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.)
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 220.127.116.11,
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.
A reason to believe that both are
intended here is that the text in the Fortran 90 standard
(Subclause 18.104.22.168 of the Fortran 90 standard) from which the
quoted text was derived was described in a way that included
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 (22.214.171.124).
If the "allocation status" of the pointer may be changed only
through the dummy argument, then the last part of that clause
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
>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.)
............................Malcolm (on holiday).
More information about the J3