Dan Nagle wrote:
> I'm afraid I don't see this as much of a question.
> What's important is the values of lb, ub, and
> not where those values originate nor how they were computed.
The question was whether this is a runtime-only (as you claim) or a
compile time checkable (given the whole program and a super-smart
compiler) constraint. I am aware that the standard constrains the
programmer (shall, etc.) so the compiler does not have to check
anything, but many implementations do keep internal track in the
descriptors of allocation and I am wondering if we are constraining
them to do possibly a lot of extra work at *every* array pointer
assignment.
And to illustrate that this is not a stupid question as you say, the
following program for example crashes with the Intel compiler, and you
say it should not. Only Absoft of the compilers I have to try actually
detects a stride of 2 at runtime---the rest pretend all was OK. So
there is obviously differences in interpretation here.
program test
real, dimension(:), pointer :: a, b
integer :: lb, ub, st
read(*,*) lb, ub
allocate(a(lb:ub))
read(*,*) lb, ub, st
b=>a(lb:ub:st)
deallocate(b)
end program
Testing:
[1901 tmp @ atom]$ dealloc.x
1 1000
1 1000 1
forrtl: severe (173): A pointer passed to DEALLOCATE points to an array
that cannot be deallocated
Aleks
|