(j3.2006) deallocating pointer function results

[Van Snyder]

On Tue, 2015-11-03 at 02:34 -0800, Robert Corbett wrote:
> The following message is based on a thread on comp.lang.fortran.
> All references are with respect to Fortran 2008.
> 
> Consider the following program:
> 
> !-----------------------------------------------------------------
> 
> program main
> 
>     deallocate( new_int() )              ! (1)
>     call my_deallocate( new_int() )      ! (2)
>     call hmm_deallocate( new_int() )     ! (3)
> 
> contains
>     function new_int()
>       integer, pointer :: new_int
>       allocate(new_int)
>       new_int = 3
>     end function
> 
>     subroutine my_deallocate(p)
>       integer, pointer  :: p
>       deallocate( p )
>     end subroutine
> 
>     subroutine hmm_deallocate(p)
>       integer, pointer  :: p, q
>       q => p
>       deallocate( q )
>     end subroutine
> end
> 
> !-----------------------------------------------------------------

> The statement marked (2) leads to prohibited behavior.
> Subclause 5.3.10, paragraph 5, states
> 
>        If no INTENT attribute is specified for a dummy argument,
>        its use is subject to the limitations of its effective
>        argument (12.5.2).
> 
> 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 doubt that any existing implementation catches this error.)

I don't see a problem here.  The function reference doesn't appar in the
deallocate statement.  Argument association is not textual substitution.
Weren't there versions of Algol that allowed a formal argument attribute
that said "every time you reference the formal argument, go evaluate the
expression for its corresponding actual argument?"  Was that "call by
name?"

> I think that the behavior that results from the statement
> marked (3) is intended not to be permitted.  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".  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 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.

I believe the intent was to cover both allocation status and association
status.  I also believe that the intent was that one is not allowed to
affect the allocation or association status of the dummy argument by
accessing the corresponding actual argument by use, host, or storage
association, and allocating or deallocating the actual argument thereby.
Whether one changes the association status of a dummy argument by
associating a local pointer with it, and then deallocating that pointer,
is perhaps a valid topic for an interp.

Suppose one has allocatable actual and dummy arguments.  Suppose one
accesses the actual argument by host association.  Suppose one uses
MOVE_ALLOC to move the allocation status from the actual argument to the
dummy argument.  The allocation status of the dummy argument has not
changed.  Is that permitted?

On the other hand, suppose X is allocatable and allocated, and one
executes

  call move_alloc ( X, X )

13.7.118p6 (in 10-007r2) says X (FROM) has become deallocated.  But
13.7.118p4 says X (TO) has become allocated.  The TO argument
description says it's INTENT(OUT), so the first thing that happens is to
deallocate X.  But 13.7.118p4 says that TO (X) becomes allocated if FROM
(X) is allocated "on entry."  Is "on entry" before or after INTENT(OUT)
deallocates it?  Is X allocated or deallocated after the call?  If
allocated, was its allocation status "affected?"

Do we need to add a caveat about FROM and TO being different entities?
Does this need an interp?

> 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).
> 
> If the "allocation status" of the pointer may be changed only
> through the dummy argument, then the last part of that clause
> is unnecessary.
> 
> I would like to know if anyone disagrees with my conclusions.
> 
> Robert Corbett
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3