# Aliasing issue with zero-length array

**URL:** <https://fortran-lang.discourse.group/t/aliasing-issue-with-zero-length-array/9012>\
**Category:** Help\
**Created:** [December 29, 2024, 8:23pm UTC](https://fortran-lang.discourse.group/t/aliasing-issue-with-zero-length-array/9012 "2024-12-29T20:23:31Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [December 29, 2024, 9:42pm UTC](https://fortran-lang.discourse.group/t/aliasing-issue-with-zero-length-array/9012/3 "2024-12-29T21:42:47Z")

</div>

> [@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,

```fortran
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](https://fortran-lang.discourse.group/t/poll-refactoring-a-chunk-of-legacy-code/2796)).

---

_[View the full topic](https://fortran-lang.discourse.group/t/aliasing-issue-with-zero-length-array/9012)._