Aliasing issue with zero-length array

[ivanpribec]

@urbanjost

leading to a lot of effort when the argument is not intent(in).

In this case, both u and v are used as intent(inout). I happened to notice the bug by accident, because in another subroutine (not shown or mentioned above) the statements,

u(1:neqn) = 1.0
v(1) = 0.0          ! oops, aliasing...

got executed (with nv = 0), and the surprising result was that u(neqn) became 0.

@urbanjost

Now has the confusing issue as to whether to treat it as arr(*) or liternally, as you can now have an array with one element

I realized that, especially in connection to bounds checking, because v(1) now gives a false sense of “okayness” - literally one element, which goes unnoticed if v is only ever used as a dummy argument, and the array dimensions are declared inconsistently across procedures.

Thanks for the explanation. I didn’t know there was a two-element array rule. It does seem to fit with the old F66 trip count rules (a topic of this discussion: Poll: refactoring a chunk of legacy code).