http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Tue, Nov 12, 2013 at 08:13:14AM +0000, zeccav at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 > > --- Comment #7 from Vittorio Zecca <zeccav at gmail dot com> --- > I believe most times a code knows if and when the size of an array > must be nonzero, so a zerosize array would raise suspicions in > those cases. Given the description of the return value for SIZE(), a better value would be -1 as -1 is not a possible return for valid code. Using a negative value for {L|U}BOUND does not work as well as the bounds can be negative. > Anyway in my opinion gfortran run time should detect when an > unallocated/unassociated array is referenced and should raise > an error situation, except for allocated intrinsic function. > Only if that were impossible or too much time consuming And here is your answer. Time. Someone would need to rewrite a (possibly large?) chunk of the compiler (and be available to fix the new bugs introduced). > I would suggest to force it as a zerosize array > with one as lower bound and zero as upper bound for each dimension. > A clever code should detect that something is wrong and take the right > action (crashing?). A clever code would not access an unallocated or unassociated entity. The clever programmer would have written if (allocated(a)) then ! Do stuff with a end if or if (.not. allocated(a)) allocate(a(some_arra_spec) Yes, I'm aware that a programmer may want to write subroutine foo(a) real b(size(a)) where it is not possible to use the ALLOCATED (or ASSOCIATED) intrinsic. Of course, using a block if-statement as shown above would prevent calling foo with an unallocated (or unassociated) entity.
