(j3.2006) deallocating pointer function results

[Van Snyder]

On Wed, 2015-11-04 at 14:04 +0000, Bill Long wrote:
> On Nov 4, 2015, at 12:31 AM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
> 
> > 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.
> 
> 
> The fact that deallocation of a pointer causes it to become
> disassociated is clearly stated in 16.5.2.4(2).  While entirely
> expected, I don?t see a corresponding statement in that subclause that
> a pointer that is argument, host, or use associated with a pointer
> that is deallocated also becomes disassociated.  Should there be a
> statement like that in 16.5.2.4 (Events that cause pointers to become
> disassociated) ?   It then becomes relevant how the statement is
> worded.  If ?A pointer becomes disassociated if it is argument, use,
> or host associated with a pointer that becomes disassociated.?, then
> the case of the argument in the caller being a function reference is
> not a problem, since there is no ?pointer? in the caller that is
> argument associated.  
> 
> If the ?pointer disassociation? for the actual argument is not
> relevant, I don?t see any reason to disallow deallocation of the
> corresponding dummy pointer.  The effect is to just deallocate the
> target of the dummy pointer, which is the same as the target of the
> pointer result of the function reference in the caller.   Certainly
> that?s analogous to what happens if the pointer dummy is defined or
> becomes undefined - operations that affect only the target of the
> pointer. 
> 
> Allowing the deallocation of the dummy argument does not seem to be a
> problem in terms of implementation,  And it is more consistent with
> our concept of a function reference that returns a data pointer being
> a ?variable?. 

If the dummy argument cannot be deallocated, a memory leak might occur.

It seems counterintuitive to require

  p => f()
  call sub ( p )

just so that sub can deallocate the pointer when it's finished with it.

> Cheers,
> Bill
> 
> Bill Long                                                                       longb at cray.com
> Fortran Technical Support  &                                  voice:  651-605-9024
> Bioinformatics Software Development                     fax:  651-605-9142
> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3