...
> > But Van was talking about the case of a dummy argument _without_ the
> > POINTER attribute!
>...
>I know of no problems with the extension Van suggests. It's probably
>an extension I'd find useful, in fact.
There are some other cases where the status of a pointer is
ambiguous and the standard needs claraification, and maybe
more features.
1) Is a given pointer deallocatable? Many people are advised
to use the ASSOCIATED intrinsic function to determine whether
DEALLOCATE can be applied to the pointer, but that test is
not sufficient. A pointer may not be deallocated if it associated
with a target that wasn't created by an ALLOCATE statement.
Even then, it can't be deallocated if it is associated with an
ALLOCATABLE entity (array in F90, f200x says entity). A
pointer that is associated with only a slice of its target may not
be deallocated. A useful test would be whether a pointer is
deallocatable (this test might sometimes be useful even if you
don't intend to deallocate, but simply want to know if any of the
above constraints are not true).
2) If a pointer is associated with an allocatable variable:
p => a
then ASSOCIATED(p) will be .true. even if A is not yet allocated.
When A is subsequently allocated, is P still associated with it? As
I read the standard, I can't find an answer to this - I would prefer
it to be true. Since arrays may be allocated with zero size (so
SIZE(P) .ne. 0 is not a test of the allocation status of P), there is
not even a way to determine (from the pointer only) whether its
target is allocated or not. That would be a useful kind of test.
Note: the F200x document has some language that *seems* to imply
that allocating a variable will have the effect of allocating any variables
that are associated with it. But, this seems to be referring to association
through host association and argument association. There is a note
which explicitly mentions pointers as not necessarily being intended
here.
--
J. Giles
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
