On Oct 15,  3:29pm, Malcolm Cohen wrote:
> Subject: Re: F90 and Purify
> Peter Shenkin said:
> > Finally, F90 itself gives you some facilities that are missing
> > from C that supply some of the functionality you need.  For
> > example, if you are always careful to check the return status
> > of ALLOCATE and DEALLOCATE, you can catch things that, in C,
> > you could only get from Purify (like attempting to free an already 
> > free-ed array).
> 
> This is only caught in Fortran 90 if the second "free" attempt is through
> the same variable.  If you have an alias for the target being deallocated,
> you are just not allowed to do anything with it.
> 
> The only errors that DEALLOCATE is required to return a STAT= value for are
>   - deallocating an unallocated allocatable array
>   - deallocating a nullified pointer
> [The above two mean that it will catch a "deallocate twice" situation when
> the second deallocate is via the same variable].
>   - deallocating a pointer that points to storage that was not obtained via
>     allocate, i.e. the pointer was pointed at a TARGET using pointer assignment
> [Most compilers get this right but not quite all].
> 
> Also, even if other errors are detected, there is no guarantee that the
> program will be terminated with an informative message rather than
> returning a STAT= value; this approach is even preferable during
> development and testing at least, since the programmer cannot hide such a
> result by using a STAT= variable.  [And thus I would recommend not using a
> STAT= at all on the DEALLOCATE so as to avoid the need to check it, since
> without a STAT= the program will be terminated - hopefully with an
> informative message!]

Thanks for the clarification of what the standard requires.  Even
this is more than you get from C;  furthermore, some compilers might
go further than the standard requires.  I certainly have benefited
from this facility (whether in a standard-required or a standard-
augmented context, I do not recall).

As far as use of STAT= is concerned, my practice differs.  I
*always* use it, check it, and print out the informative message myself
(so that I don't have to "hope" for one);  and I have a methodology
I always use for new code that returns to the calling function and
prints another message there;  then returns to the next caller, etc.,
till I exit from the main PROGRAM.  That way I see an annotated
call stack should the program die.  

This is a lot more useful than just knowing that the program died in
an ALLOCATE or DEALLOCATE statement, even if one also knows the
name of the routine it died in -- since often, routines that
do these operations are at a rather low level and could have
been called from anywhere.

It's hard to retrofit old code with this, and it takes discipline,
but it's well worth it, at least for me, for new code.  YMMV.

	-P.

-- 
*** "Freedom's just another word for nothing left to lose." (B. Yeltsin)***
*Peter Shenkin; Chemistry, Columbia U.; [log in to unmask] (212)854-5143*
*MacroModel WWW page: http://www.columbia.edu/cu/chemistry/mmod/mmod.html *


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%