(j3.2006) a question on c_f_pointer call

[Malcolm Cohen]

I agree completely with Aleks.

What's more, correct operation of DEALLOCATE on a valid pointer deallocation is not up for auction.  All the witter about internal implementation stuff is irrelevant - the pointer is a valid pointer to a deallocatable target and so the DEALLOCATE absolutely must succeed.  Otherwise you're saying it's "not really" a valid pointer.  No way.

This situation most definitely was "carefully considered", why do you think the feature is in there!  Some might dislike it now, but that doesn't mean we didn't deliberately add the feature.  Removing features might make implementation easier, but if we are going to go down that route there is a list of features that are many orders of magnitude more difficult to implement than this, so if we're going to rip stuff out we can rip out the stuff that hardly anyone has implemented, not bits of C interop which most of us have done correctly already.

The requirements for producing error conditions for particular erroneous circumstances might seem onerous to some (including myself), but speaking as an implementor, NAG put in the work to make it work.  A long time ago.  I think it is a bit too late to revisit that one too.

Note that the third example is not standard-conforming.  NAG produces a hard error for that one (not catchable with STAT=).


From: Aleksandar Donev 
Date: ?? 22?8?26? 4:23
To: fortran standards email list for J3 
Subject: Re: (j3.2006) a question on c_f_pointer call


On 08/25/10 15:02, Jim Xia wrote: 
  The question is: does standard require specific behavior on each of the DEALLOCATE statement?  I found the standard is vague in this. 

It seems pretty clear to me. The intent is that it does not matter whether the association of the pointer happens via pointer assignments or with c_f_pointer. The most important rule is the one about:
"If a pointer appears in a DEALLOCATE statement, it shall be associated with the whole of an object that was created by allocation."


-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20100826/ba7d75fd/attachment.htm>