(j3.2006) a question on c_f_pointer call

[Bill Long]

Malcolm Cohen wrote:
> I agree completely with Aleks.
>  

I think we all agree with Aleks about what the standard currently says.

> What's more, correct operation of DEALLOCATE on a valid pointer 
> deallocation is not up for auction.  All the witter about internal 
> implementation stuff is irrelevant - the pointer is a valid pointer to a 
> deallocatable target and so the DEALLOCATE absolutely must succeed.  
> Otherwise you're saying it's "not really" a valid pointer.  No way.

It hinges on "valid pointer".  Certainly there are valid pointers that 
cannot be deallocated, such as ones with explicit-shape or allocatable 
targets.  The issue is the restrictions on which valid pointers are 
allowed in deallocate.


>  
> This situation most definitely was "carefully considered", why do you 
> think the feature is in there!  Some might dislike it now, but that 

The question was the "carefully considered"  side effects of 
C_F_POINTER on pointer deallocation.  Evidently that discussion took 
place before I joined the committee.  I assume it went something like 
"We realize that requiring a pointer that was associated via C_F_POINTER 
to a target that was originally allocated as a pointer should be allowed 
in deallocate, despite the fact that it will break many long-established 
methods for tracking pointer deallocatability, and that the alternative 
methods have significant performance hits.  The value in making this 
obscure avenue work is worth degrading the performance of all existing 
codes that deallocate pointers."  I'm quite sure I would have remembered 
that discussion.


> doesn't mean we didn't deliberately add the feature.  Removing features 
> might make implementation easier, but if we are going to go down that 
> route there is a list of features that are many orders of magnitude more 
> difficult to implement than this, so if we're going to rip stuff out we 
> can rip out the stuff that hardly anyone has implemented, not bits of C 
> interop which most of us have done correctly already.
>  
> The requirements for producing error conditions for particular erroneous 
> circumstances might seem onerous to some (including myself), but 
> speaking as an implementor, NAG put in the work to make it work.  A long 
> time ago.  I think it is a bit too late to revisit that one too.
>  

There is always resistance to fixing past mistakes, but it does happen. 
  More easily if it is estimated to have almost no impact non-contrived 
programs. Or if it involved an overlooked side effect that was missed in 
integration.


> Note that the third example is not standard-conforming.  NAG produces a 
> hard error for that one (not catchable with STAT=).
> 

The second example is also not standard-conforming (no compiler tested 
allowed this one through).  The third example did get a runtime error 
from at least two compilers.  I don't see why this one is "not catchable 
with STAT=".    Consider this example:

!  file1:
    subroutine sub(p,i)
	real,pointer :: p(:)
	integer,intent(out) :: i
	
	deallocate (p, stat=i)
   end subroutine sub

! file 2:

    program test
       interface
           subroutine sub(p,i)
               real,pointer :: p(:)
               integer,intent(out) :: i
           end subroutine sub
        end interface
	integer :: istat
	real,allocatable,target :: a(:)

	allocate (a(100))
	call sub(a,istat)
	print *, istat

   end program test

In sub, the pointer p is associated with an allocatable target, so a 
non-zero value for i should result.   Assuming that file 1 was 
separately compiled, the .o put into a library in a far-away directory, 
and then the source and .o deleted, it is hard to image the compiler 
catching this case at compile time.  This should be catchable at run 
time.  It is unclear to me why this is not a requirement.

The same issue occurs if sub had been written in C and the deallocate 
was attempted via CFI_deallocate.  I assume this is the motivation 
behind Tobias' request that the needed deallocatability  information be 
included in the C descriptor.

[John separately pointed out that the CFI_deallocate routine does not 
have the same rules as DEALLOCATE. This was not the intention, and needs 
to be fixed in the TR. The assumption was that common library code would 
be used to implement both CFI_deallocate and DEALLOCATE.]


Cheers,
Bill



> *From:* Aleksandar Donev <mailto:donev at courant.nyu.edu>
> *Date:* ?????? 22???8???26??? 4:23
> *To:* fortran standards email list for J3 <mailto:j3 at j3-fortran.org>
> *Subject:* Re: (j3.2006) a question on c_f_pointer call
> 
> On 08/25/10 15:02, Jim Xia wrote:
>> The question is: does standard require specific behavior on each of 
>> the DEALLOCATE statement?  I found the standard is vague in this.
> It seems pretty clear to me. The intent is that it does not matter 
> whether the association of the pointer happens via pointer assignments 
> or with c_f_pointer. The most important rule is the one about:
> "If a pointer appears in a DEALLOCATE statement, it shall be associated 
> with the whole of an object that was created by allocation."
>  
> -- 
> ................................Malcolm Cohen, Nihon NAG, Tokyo.
> 

-- 
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