(j3.2006) C_LOC and deallocating a pointer
Mon Jun 20 13:54:13 EDT 2016
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.
> -----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))
> 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
> Bill Long
> longb at cray.com
> Fortran Technical Support & voice:
> 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
> 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
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
More information about the J3