(j3.2006) C_LOC and deallocating a pointer

[Bill Long]

On Jun 16, 2016, at 8:47 PM, Cohen Malcolm <malcolm at nag-j.co.jp> wrote:

> Case 1 is valid if the allocation was via the ALLOCATE statement.  If it was 
> not, the program is not standard-conforming, and there is no requirement to 


The wording in 16-007r1 is:

"Deallocating a pointer that is disassociated or whose target was not created by an ALLOCATE statement causes an error condition in the DEALLOCATE statement. "

That seems like specified semantics, not something non-conforming.  Generally, when we say something causes an error condition it is a runtime situation that is intended to be flagged, and not an indication of a non-conforming program.

I?d note that F2003 went on to say that if an error condition (like this) occurs, and there is no STAT= specifier, the program terminates.  That seems to be missing in F2008, but is back in F2015, since another such ?error condition? is a failed image.  (16-180r2). 

The following sentence in 16-007r1 is:

"If a pointer is associated with an allocatable entity, the pointer shall not be deallocated.?

This is a clear case of ?shall not?, so a program that does this is not conforming.   In this case, I agree that there is no requirement to raise an error. 


> raise an error.  OTOH there are multitudinous implementation techniques 
> which can detect this error should that be considered desirable.
> 

The two I know about either cannot detect this (include the information in the dope vector), or have horrible performance implications (maintain a database).  I?d much refer to add a limitation along the lines of "a pointer created by C_F_POINTER shall not be deallocated", and not have to choose the bad second option.


> Case 2 is not valid.  There is no requirement to detect this error. 
> Nonetheless, it is detectable.

Case 2 seems to come under the first quote above, and should raise an error condition.


> 
> Case 3 is also not valid.  Again, there is no requirement to detect this 
> error.  Again, the error is detectable and there are implementations which 
> can detect it.  There is no significant difference between this situation 
> and one arising without the use of C_LOC or interoperability.

I agree that this is a conformance problem and a message is not required. 

> 
> The rules are simple:
> (1) if you allocate it via Fortran, you must deallocate it via Fortran;
> (2) if you allocate it via C, you must deallocate it via C;

Well, except for using the new C interop routines CFI_allocate and CFI_deallocate. 

> (3) if it is a Fortran ALLOCATABLE you must not deallocate it except via the 
> ALLOCATABLE variable.
> 
> And it is not required to detect violations of any of these rules. 
> Nonetheless, it is not hard to do so should that be felt desirable.

But I would argue it is hard to do efficiently, and harmless to prohibit, since we now have much better ways to allow for cross-lanugage allocation and deallocation.

Cheers,
Bill

> 
> Cheers,
> 
> -----Original Message----- 
> From: Bill Long
> Sent: Friday, June 17, 2016 6:21 AM
> To: fortran standards email list for J3
> Subject: (j3.2006) C_LOC and deallocating a pointer
> 
> 
> In general, if you try to deallocate a pointer, the memory involved should 
> have been allocated by allocation of a pointer.   Thus, for example, if the 
> target of the pointer is a explicit-shape array or is allocatable, there is 
> an error. That is all pretty clear if you stay in the Fortran domain. 
> However, what about cases like this:
> 
> 
> type(C_PTR) :: px
> integer,pointer :: p(:), q(:), r(:)
> ?
> ! Part A - somehow allocate memory for p
> ?
> q => p
> px = C_LOC(q)
> 
> ! Part B - Pass px to a C function that uses it somehow
> 
> call c_f_pointer (px, r(100))
> deallocate(r)
> 
> ========
> 
> Case 1:  Is this ever legal, independent of how P was allocated in Part A? 
> The variable px contains only the C address of the target - all the Fortran 
> ?pointer? information is lost (with typical implementations) at this point. 
> So the deallocation of r does not have sufficient information to determine 
> whether the deallocate should generate an error.
> 
> Case 2: In part A the memory is allocated by malloc() in a C function. How 
> would the deallocate know that the C allocation was for 100 elements?
> 
> Case 3: The declaration for P is, instead, allocatable,target, and the 
> memory in Part A is allocated by a Fortran ALLOCATE statement. In this case 
> the runtime should raise an error, but is there sufficient information to 
> determine that?  Unfortunately, compilers are not in agreement about this 
> case.
> 
> 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
> 
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star.
> ________________________________________________________________________
> 
> -- 
> ........................Malcolm Cohen, Nihon NAG, Tokyo. 
> 
> _______________________________________________
> 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