(j3.2006) C_LOC and deallocating a pointer
Tue Jun 21 01:14:59 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
> not, the program is not standard-conforming, and there is no requirement
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
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
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
Apart from being incompatible with F2003 and F2008, that is totally
unacceptable. You have to be able to DEALLOCATE a pointer that was
> 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
"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
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
> 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
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!
........................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3