(j3.2006) finalizing undefined entities -- odd text in 6.6.4

[Bill Long]

Jim Xia wrote:
>
> j3-bounces at j3-fortran.org wrote on 03/18/2008 04:00:57 PM:
>
> >
> > How about
> >
> >          DEALLOCATE (pointer, stat=istat)
> >
> > This would need to be done separately for each pointer; otherwise,
> > there is no
> > certainty that each valid target is deallocated.
> >
> > Cheers,
> >
> > John.
>
>
> That works for pointers assigned to a target that is not eligible for 
> deallocation.  However in cases where the pointer is un-initialized 
> and is therefore with garbage value, specifying stat= is not really 
> helpful.  The DEALLOCATE statement may cause the program to die.
>

Really??  My interpretation has been that including the stat= specifier 
should prevent the program from aborting.

If the user really wants to deallocate a pointer's target in a FINAL 
routine, then John's scheme seems reasonable.  If he wants to do 
something else, like dump the values to a saved location before deleting 
the target, then there are still issues.

This exchange prompted me to read clause 6.6.4 STAT= specifier in 
08-007r2.  The end of paragraph 3 seems odd.  It says "In either case, 
each <allocate-object> has a processor-dependent status:"  which is 
followed by a list of 3 cases that seem to cover all the bases and allow 
for no processor-dependence at all.  This is dutifully duplicated in 
Annex A.  What processor-dependence is being specified here??   To 
follow up with Mike's earlier comment, the Note 6.25 that follows the 
list says that ASSOCIATED can be used to get more information, but as 
Mike noted, that is not always true.

Cheers,
Bill




-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120