(j3.2006) Frustrating consequence of F2003 allocation semantics

[Malcolm Cohen]

<<<
INTEGER, ALLOCATABLE, TARGET ::  buffer(:)
...
ptr => buffer
?
buffer = C
...
suppose that there is a bug in the code, such that one of the arrays on the RHS 
is of a _different_ shape than buffer.   F2003 semantics will have buffer 
reallocated to an appropriate shape for the copy.     Previously one would 
expect that proper use of debug flags would quickly localize the problem.
>>>

A few comments:

(a) I agree with Damian that using whole section notation works, and gives a 
clear indication that you're not auto-reallocating.

(b) The NAG compiler will not only tell you the pointer is dangling, but why, 
and where the deallocation happened.

(c) You can declare buffer to be POINTER instead of ALLOCATABLE, even 
POINTER,CONTIGUOUS (if the compiler supports it).   There is no 
auto-reallocation for pointers.  POINTER,CONTIGUOUS should perform at about the 
same level of ALLOCATABLE,TARGET (because TARGET already made this perform 
poorly).

(d) If buffer is so important and fragile, maybe it should be PROTECTED so it 
can only be set in the module.  Then the program can do its own validation of 
shape, and/or modify the pointers accordingly, whatever.

(e) Finally, I don't really agree that the pre-F2003 situation is quite as rosy 
a picture as painted.  If you get the shape wrong, you are liable to scribble on 
some unrelated memory.  Sure, if you are *lucky* that will cause a crash then or 
sometime soon, but if it ends up just modifying the value of some unrelated 
variable(s) you might never know that the answers produced are wrong.  And thus 
not run with checking enabled...

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.