ALLOCATE and STAT, take 2

[Janne Blomqvist]

On 6/5/07, Salvatore Filippone <salvatore.filippone@uniroma2.it> wrote:
> Hi,
> Further to our previous discussion about the possible ways for ALLOCATE
> to fail, I went ahead and built an example where the allocation size
> overflows into positive integers (on a 32 bit machine), and here's the
> outcome.
> Ideas on what can be done? Note that here we have
> (SIZE(X,1)>0).and.(SIZE(X,2)>0).and.(SIZE(X)<SIZE(X,1))
> which ought to be impossible.

As long as the hardware doesn't provide hardware trapping of integer
overflow, I don't think we can easily provide a bullet proof solution.
So the user just has to be aware that when doing very big allocations
there might be issues. Now, a couple things:

1) The size parameter to the allocate routines in libgfortran should
be of type size_t. The frontend already generates code to check that
the size of all the dimensions are > 0, so there's not much point
repeating that in the library that we can do when using a signed size
type, especially as the size might wrap around to positive values just
like your example shows. This way we can also get rid of separate
allocate and allocate64 routines, since size_t is always the correct
type. And we can allocate bigger arrays than with a signed type of the
same size as size_t.

2) As of F2003, the size intrinsic accepts an optional kind parameter
specifying the kind of the return value (I don't remember if gfortran
supports it, at least 4.1 doesn't). The user needs to supply an
appropriate kind if the size is bigger than what fits into a default
integer.

-- 
Janne Blomqvist