(j3.2006) Frustrating consequence of F2003 allocation semantics

Tom Clune Thomas.L.Clune
Tue Apr 14 10:05:06 EDT 2015


While in a debate with a client about being certain that we use appropriate flags to activate F2003 allocation semantics, the client came back with this somewhat realistic scenario:

(1) We have a module variable declared as:

INTEGER, ALLOCATABLE, TARGET ::  buffer(:)

(2) During initialization this array is allocated and provided initial values.   Then, one or more pointers is set to point at that array.

	ptr => buffer

(3) Outside the module,  various whole array assignments are done to buffer.

	buffer = A
	?
	buffer = C

No issues so far.  Now, however, 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.

Unfortunately, F2003 semantics results in all pointers to buffer becoming invalid, while buffer itself is ?fine?.    We now have dangling pointers and a very difficult time tracking down what went wrong - the symptoms are highly nonlocal.    Debugging flags might help us discover that the pointer is dangling, but they won?t help much in tracking down the cause.


There are of course several stylistic ways to avoid using the F2003 automatic reallocation in this scenario,  but it would be difficult to enforce across an <ahem> ?diverse' developer team.

Does anyone have a good argument to push back on my client?   Is anyone else concerned about the implications of this example?

Cheers,

- Tom










-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150414/44ca276b/attachment.html 



More information about the J3 mailing list