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

James Tursa <aklassyguy@xxxxxxxxxxx> wrote:

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

passing an unallocated allocatable as
an actual argument is already invalid

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

Oh. Then you are pretty much out of luck in terms of anything standard
or portable. I've been there. Not quite this case, but other ones where
I needed to try to catch errors of other users. In one case, some users
could write subroutines that were used with my program. Yet other users
would use the combined package. Try as I might, I just could not get
some people to code with adequate robustness. They would do things like
take square roots of values that might be negative. Sure the physical
quantity modeled couldn't be negative, but imperfect instrumentation
could and did sometimes end up with negative values.

I ended up writing an exception handler to catch this stuff (and using
nonstandard C interop tricks to install it). I couldn't really count on
being able to recover and continue. But at least I could get out a
message saying what kind of error had occurred and where. Without that,
all the final user saw was that he had gotten dicsonnected from the
server. This was a client-server application (using other C interop
tricks), with the user not even having an account on the server machine.
My exception handler and message at least directed the users to the
right person. Before I put that in, the questions all came to me.


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...

or quite likely upstream. Recall that it is the call in the firt place
that is invalid. There is at least a chance of getting a run-time error
on the call.

As a side question, is there some philosophical reason why size(x,1)
for unallocated x should't be allowed to simply return 0?

First note that you don't have an unallocated array in the subroutine.
It is the actual argument that is unallocated. As mentioned above and
before, the problem is in the subroutine call in the first place - not
in the use of the size intrinsic. Yes, there are huge philosophical
reasons why the standard doesn't define what happens afterwards when you
have already done something nonstandard beforehand. But I assume that's
not what you are really asking. If so, that's too big and basic a matter
for me to cover in finite space.

But supposing you did have an unallocated allocatable, insisting that
size of it return 0 is much like insisting that any other undefined
expression return 0. If you expect the size to return zero, then how
about just x(42). Why not also ask that to return zero?

Also, it is comparable to disassociated or undefined pointers. In that
case, there would be serious implementation problems (and likely
performance penalties) from insisting that it always be valid to ask
about the size of any such pointer array. That would pretty much amount
to getting rid of the concept of undefined association status and
forcing the compiler to keep track of all cases where pointers currently
go undefined. Otherwise, you end up with pointers that "look" valid, but
point to space subsequently reused for other things. While it is
probably possible inprinciple, that is a lot bigger implementation mess
than intended.

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)?

Again, you keep bringing up size. This has nothing to do with the size
intrinsic. It is the call that is invalid. And I woudln't say that the
compiler has to "allow it". More a matter that the compiler might not
detect the error. As to the "philosophy" of it, I would say that you are
concentrating more on the implementation details than on the
abstractions. The abstraction is that if the variable is unallocated,
there is no array to pass. That model can translate into implementation
matters. Imagine copy-in/copy-out schemes.

Note, by the way, that there are applications that make useful
distinction between an array being unallocated versus being allocated
with size zero. In one case, you don't (yet?) know how big it is (will
be?). In the other case, you have established the size and know that it
is zero.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: code optimiation
    ... Given that the compiler can often optimise the generated code to use the best sized types available, it's seldom worth specifying "fast" types explicitly. ... pointers and floating point types whose "zero value" might not be all- ... instruction, so the assembler produced for *p++ when used as the ... It will do the same job, and let you write the source code using proper array constructs. ...
    (comp.arch.embedded)
  • Re: How to retrieve data from array of pointers or from a struct?
    ... You're declaring an array of pointers to unsigned long long, ... you're initializing the pointers with integer values. ... and your compiler should have warned ... You're not explicitly calling memcpy, ...
    (comp.lang.c)
  • Re: Strange programming problem
    ... Depending on how your array is allocated, ... >the compiler can do range checking. ... of memory without limit using pointers, so you can screw up any part ... Saying that a good and careful programmer ...
    (comp.os.vms)
  • Re: folder parsing (newbie)problem
    ... this is an array of char*. ... If so you are using a weird compiler. ... you should probably read up on pointers and on malloc. ...
    (comp.lang.c)
  • Re: Array of class and a pointer to it
    ... the above line is invalid. ... > not a two-dimensional array, which is what the OP wants. ... It is array of pointers to pointers. ... first operator[] take the pointer to the array of values the second ...
    (microsoft.public.dotnet.languages.vc)