(j3.2006) a question on c_f_pointer call

[Bill Long]

Aleksandar Donev wrote:
> On 08/25/10 17:20, Bill Long wrote:
>> Would a restriction like this work: "A pointer cannot be deallocated 
>> if its association was established by C_F_POINTER" ?
> Before we go down that route, let's ask whether the problem is not that 
> we require error reporting that is too much of an imposition on 
> implementations? That is, if the compiler is not required to set the 
> stat correctly, is there a problem? 

It rather diminishes the usefulness of the stat value.  The particularly 
problematic case is if the stat comes back zero and the memory did not 
actually get deallocated.

>We had a long argument about the 
> words that are there for Fortran pointers. The original words said 
> something like "whole of a target", and then we changed to what is there 
> now via an interp. The intention of the present words, it seems to me, 
> is that as long as you have a pointer that points to a whole block of 
> memory that was allocated via ALLOCATE, you can deallocate. 

This is what the current words say, and more clearly than the old words. 
   The question that I believe Jim raised is whether we overlooked the C 
pointer path case and maybe should consider changing (or adding to) the 
words.   I just suggested possible new words that address the issue 
raised, if we decide there is a problem and want to fix it.

I think the discussion ultimately comes down to an implementation issue. 
  If the deallocation information is carried in the Fortran descriptor, 
then Jim's Case 1 is very difficult to track.  If the ability to 
deallocate is stored in a separate data structure, then the information 
could survive the trip through C pointer land.  But there is likely a 
performance penalty for such an implementation, and most vendor's 
customers are performance sensitive. They could object to the penalty if 
the only reason is to allow detection of a case the would normally not 
occur anyway.

> It does not 
> matter how the pointer itself got the information. Malcolm wrote the 
> majority of the interp answers, and maybe he can give a reasoning and an 
> answer that is consistent with how we answered that interp.

Certainly Malcolm's input on this would be very relevant.

Cheers,
Bill


> Aleks
> 

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