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

James Tursa wrote:
(snip)

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.

There are an infinite number of possible errors that one can
make, and it is not reasonable to consider checking for all of them.

If you use an ALLOCATABLE dummy, then you have the ability to
check for it. Note, though, that your subroutine can't stop the
caller from using an unallocated ALLOCATABLE array outside the
subroutine.

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?

I don't know that it is disallowed, it just isn't required.

This isn't much different from the use of other undefined
variables where you get whatever happens to be stored in that
memory location.

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.

Among other reasons, in some cases it is necessary to pass a copy
of the array to the called routine. In that case, copying an
unallocated array likely references an address containing an undefined
value, and that is before actually calling your routine.

-- glen

.

Relevant Pages

  • Re: IF statement fails
    ... > was not recognized by the compiler for some reason). ... > re-type the code and sometimes I've had to retype the entire routine in ... I'm going to restructure the routine ... ...
    (borland.public.delphi.language.objectpascal)
  • Re: Why does this work?
    ... The standard generally only imposes compiler ... referencing an unallocated array. ... do you really want runtime code to check that every ... During the program writing phase, it's nice to be able to write ...
    (comp.lang.fortran)