Re: Q: Checking the size of a non-allocated array?

On Thu, 9 Aug 2007 21:56:21 -0700, nospam@xxxxxxxxxxxxx (Richard
Maine) wrote:

James Tursa <aklassyguy@xxxxxxxxxxx> wrote:

For an allocatable array that is not
currently allocated (the second call from myprog), subroutine mysub
will call size(x,1) and get zero (at least with my setup). This lets
the subroutine know not to try to access the elements, and it will
return without doing anything. Problem is, the documentation I have
been reading says size(x,1) for an unallocated array x is undefined.
So I suspect I am doing something that works with my setup but is not
part of the standard. Is this true? And if so, then how can I code
the subroutine to know if the passed array can be accessed?

Yes what you are doing is nonstandard. But the problem is more
fundamental than you are thinking. passing an unallocated allocatable as
an actual argument is already invalid (unless the dummy argument is
allocatable, which requires either the F95 TR or f2003). That call being
invalid in the first place, by the time you get to the subroutine, it is
too late.

Absolutely the only way that it is valid to pass an unallocated
allocatable as an actual argument is if the dummy is allocatable. But if
the dummy is allocatable, then the actual always has to be allocatable.

I don't know enough about the context to know what to suggest, but the
direction you seem to be looking towards won't work.

If it fits your application, one approach might be to allocate the
allocatable as size zero. That is then perfectly fine. There are some
people who get confused about the distinction between an array being
allocated to size 0 and not being allocated. There is a distinction and
it is important. It might concievably help your application.

The subroutine in question is intended to be part of a library that
other users will call. i.e., I don't have control over what they may
write so I am trying to be as nice as possible and catch their errors
and return gracefully. I do understand the distinction between
unallocated vs allocated with size 0, but I can't be sure that the
users of the library will. I know that they *shouldn't* call the
routine with an unallocated array, and it will be documented as such,
but they might do it in error and I was trying to catch it and return
with an error code rather than letting worse things happen. Sounds
like I can't do this in any standard way. So I will probably use this
construct and hope for the best. The worst outcome of this construct
would seem to be some type of run-time error on the call to size(),
but they would have gotten a run-time error anyway downstream if I
tried to access the elements (e.g., if the size() check had returned a
non-zero value for an unallocated array). At least I am giving the
compiler a chance to do something reasonable, and in my case Intel 9.1
appears to do just that.

As a side question, is there some philosophical reason why size(x,1)
for unallocated x should't be allowed to simply return 0? Seems
reasonable to me, although I suppose that means defaulting some memory
associated with x for the size to zero (or something like that) when
the variable is declared or when it is deallocated. There obviously is
*some* default status (i.e., unallocated) given to the variable by the
compiler when it is declared, so why not the size as well?

2nd side question related to the validity of putting an unallocated
array in a call to a routine that does not have the allocatable
attribute for the assocated dummy argument. Obviously the compiler has
to allow it since the compiler doesn't know at compile time whether or
not the array will be allocated at run-time. Is there some
philosophical reason for not allowing this in the standard (beyond the
fact that size() is not defined)? If this was allowed, along with
defining the size() to zero for unallocated arrays, then programmers
would have more options to make their code more robust, e.g. as in my
case.

.

Relevant Pages