(j3.2006) Frustrating consequence of F2003 allocation semantics

[Tom Clune]

Malcolm,

Thanks!  I think several of your points will have a good chance of influencing this client.

Your point (b) is of course the most surprising one to me.   Are there any special flags required?  (-g of course, but ?)

Cheers,

- Tom


On Apr 15, 2015, at 5:11 AM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:

> <<<
> 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. 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Thomas Clune, Ph. D. 				<Thomas.L.Clune at nasa.gov>
Head ASTG,Code 606
NASA GSFC		
MS 610.8 B33-C128
Greenbelt, MD 20771
301-286-4635









-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150415/c213002a/attachment-0001.html