(j3.2006) C_LOC and deallocating a pointer

[Cohen Malcolm]

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

You are quite right, I was mis-remembering how we expressed the outcome of 
the C vs. Fortran allocation semantics.

In the light of CFI_allocate, the wording is not quite right though.

OTOH, that wording is referring to the situation where the target of a 
pointer is just some local (or module or whatever) variable, possibly SAVEd, 
possibly not.  I.e., something that was not "allocated" in the more general 
sense.  It was not intended to refer to C malloc.

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

It's present in my copy.

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

You can store the info in the object header (the same place that malloc 
stores the size info), that overhead is tiny.  Since one is not permitted to 
do partial deallocations ("shall be associated with the whole of an 
object"), the standard facilities that method.

You can use memory regions, the overhead can be very small here too.  This 
detection method works even for partial deallocations!

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

Apart from being incompatible with F2003 and F2008, that is totally 
unacceptable.  You have to be able to DEALLOCATE a pointer that was 
ALLOCATEd.

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

"If a pointer appears in a DEALLOCATE statement, it shall be associated with 
the whole of an object that was created by allocation."

Since this is referring to Fortran allocation, it could be argued that C 
malloc falls foul of this.  (Well, it's not completely implausible!)  Though 
what it is really trying to say is that it has to be the whole of an object, 
i.e. no partial deallocations.

Clearly these words could do with some care and attention too.

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

Right, we ought to say that here, it is not quite good enough to have 
elsewhere that CFI_allocate "works just like ALLOCATE".

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

On the contrary, I do not think it is very hard to do efficiently.  However, 
I do not necessarily disagree that it might be useful to prohibit some 
cases, especially where the current wording is slightly ambiguous.  Just as 
long as we do not throw out the baby with the bathwater.

In particular, given

   TYPE(something),POINTER :: a,b
   ...
   IF (ASSOCIATED(a) .AND. ASSOCIATED(b) .AND. ASSOCIATED(a,b)) THEN
      DEALLOCATE(a) should work the same as DEALLOCATE(b)
      even if "a" was produced by a pointer assignment,
      and "b" was produced by a call to C_F_POINTER

otherwise we are undermining the very purpose for which we allowed C_LOC and 
C_F_POINTER of non-interoperable types back in F2003 days.

Finally, we should look very carefully at the wording of CFI_allocate and 
CFI_deallocate to make sure that it expresses our intent (to make these the 
same as ALLOCATE and DEALLOCATE) without ambiguity or contradiction.

............................................................

Anyway, a useful discussion, looks like /DATA needs to clean this up a bit!

Cheers,
-- 
........................Malcolm Cohen, Nihon NAG, Tokyo.