(j3.2006) deallocating pointer function results

[Bill Long]

On Nov 9, 2015, at 2:18 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:

> On Mon, 2015-11-09 at 19:47 +0000, Bill Long wrote:
>> On Nov 9, 2015, at 1:11 AM, Cohen Malcolm <malcolm at nag-j.co.jp> wrote:
>> 
>>> No it does not make sense.  The dummy argument (which *is* a name, thus 
>>> "name association") is associated with the effective argument, which is a 
>>> pointer, being the result of a function reference.
>>> 
>>> Thus "changes accordingly" would mean the result of the function reference 
>>> changes accordingly!  Obviously nonsense, just the same as the nonpointer 
>>> case of assigning a value to a dummy associated with an actual argument of 
>>> "X+1?.
>> 
>> So, the effective argument is a pointer.  You seem to be saying that
>> pointer cannot become disassociated.  That seems like obvious nonsense
>> to me. Pointers with the INTENT(IN) attribute have that restriction,
>> but that is not the case here.   Sure, when the procedure completes,
>> that pointer will disappear, but that is not relevant.   The effect of
>> deallocating the dummy argument is to deallocate the target of the
>> pointer that is the effective argument, and to mark both the dummy
>> pointer and the effective argument pointer to disassociated.  Simple.
>> I don?t see how that has anything to do with the ?X+1? non-anology.
> 
> No matter what we think we believe the standard says, I'm coming around
> to agree with this desire.  Otherwise, using the result of a function
> that returns a pointer result would result in a leak if that pointer was
> allocated by the function and there is not another pointer associated
> with the same target.
> 
>> I?m coming around to believe that the point of the inconsistency in
>> the original program example was that the statement
>> 
>>   deallocate (pointer_valued_func_ref( ) )
>> 
>> should be allowed, and the current text in the standard is too restrictive.

If I take the original example code

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

and comment out line (1) to avoid the clear syntax error, the rest of the program compiles and executes just fine with all the compilers I have available (Cray, Intel, PGI, gfortran).   I suspect the implementation effort associated with changing the rule and allow (1) would amount to disabling the current error message.

Cheers,
Bill


>> 
>> 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
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

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