From malcolm@brackley.nag.co.uk  Thu Mar 30 15:17:19 2000
Received: from brackley.nag.co.uk ([62.232.54.10])
	by dkuug.dk (8.9.2/8.9.2) with ESMTP id PAA26190
	for <SC22WG5@dkuug.dk>; Thu, 30 Mar 2000 15:17:18 +0200 (CEST)
	(envelope-from malcolm@brackley.nag.co.uk)
Received: (from malcolm@localhost)
	by brackley.nag.co.uk (8.9.2/8.9.2) id OAA83760
	for SC22WG5@dkuug.dk; Thu, 30 Mar 2000 14:16:15 +0100 (BST)
	(envelope-from malcolm)
From: Malcolm Cohen <malcolm@nag.co.uk>
Message-Id: <200003301316.OAA83760@brackley.nag.co.uk>
Subject: Re: (SC22WG5.1755) Semantics of the SIZE intrinsic
To: SC22WG5@dkuug.dk
Date: Thu, 30 Mar 2000 14:16:15 +0100 (BST)
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Lawrie Schonfelder said:
>Could we not have a minor extension to the standard and define the SIZE 
>intrinsic to return zero in such cases.

Well, you could define your own PURE function to do what you want here (at
a potentially significant textual cost, admittedly).  Or one can use
allocatable working arrays instead of automatic ones - which at least gives
you the chance to recover gracefully from an "out of memory" (or "out of
stack") condition which the automatic array does not.  For this reason the
NAG FL90 library uses allocatable arrays in preference to automatic arrays -
they are safer.  I concur with this design decision.

>The alternative would be to provide some way of allowing a pointer to be 
>initialised to have a zero sized array target and likewise an allocatable 
>array to a zero sized array instead of deallocated.

I think this is a red herring.  Nothing stops the user from doing
NULLIFY(pointer) and then calling your routine.  So I think that regardless
of the desirability of alternative initialisations, your "super-safe"
routine will still need to take disassociated/deallocated entities into
account.

Eliminating the difference between zero-sized arrays and unallocated
allocatable arrays has been suggested in the past (by me at least) but it
would not be possible to do in an upwards-compatible way, sadly.

Since we have gone to so much trouble to differentiate between unallocated
vs allocated with zero size etc., it seems ... strange ... to go about trying
to partly eliminate the difference now.

>In fact I would like both 
>but I would settle for the extended SIZE definition.

I'm not *entirely* convinced you should restrict yourself to SIZE - people
using POINTER arrays often want to copy the bounds not just the extents -
e.g. REAL B(LBOUND(A,1):UBOUND(A,1)).  But it is difficult if not
impossible to know what you would expect LBOUND and UBOUND to return in the
disassociated case.  Plus it would be a (slight?) irregularity - SIZE
treats disassociated as zero-size but MAXVAL does not?

Presumably you would want SIZE(P,n) also to return zero, 1<=n<=rank(P).
You might want to think about LEN(P) for an allocatable-length entity
(then again you might not).  Ditto parameterised derived type entities
with deferred parameters.

It seems to me that this is a fairly minor convenience thing rather than a
major convenience thing or a safety thing.  But I'm not opposed to it, as
long as someone else does the work...

Cheers,
-- 
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
                           (malcolm@nag.co.uk)