Revisit array warnings/errors with shopt --set strict_array

[akinomyoga]

Originally posted by @andychu in #2165 (comment)

Another thing we can do is make a hard error when shopt --set strict_array, which we already have

There is an e_strict() pattern that we sometimes use for that

Though that increases the test matrix, so maybe we can do that in another pass

I don't have the capacity to handle this in parallel with the currently ongoing bug fixes, refactoring, and SparseArray implementation of arrays.

Let's create an issue before forgetting about this.

[akinomyoga]

The above is for ${a[-1]} and $((a[-1])). The following is about test -v a[-1].

Originally posted by @andychu in #2166 (comment)

Hm the other change was just a warning, and this one is an error

$ bash -c 'test -v a[-1]; echo status=$?'
bash: line 1: a: bad array subscript
status=1

I think this argues for the e_strict() style then ... we can match bash EXACTLY if we want, but then OSH should have shopt -s strict_array, which is CONSISTENT

i.e. this part would not change, but the previous $((a[-1])) and ${a[-1]} should change to be consistent, I think

There is also a[-1]=v. In addition, each of them has codes for BashArray, BashAssoc, and SparseArray.

• Are there any other places?
• How does Bash behave?
• What would be the default osh behavior for each, and how would it be changed under strict_array?

[andychu]

OK yes, we can do this after SparseArray

I think my basic viewpoint is

• bash is inconsistent about errors. But sometimes it is easier to just copy bash, since it makes the spec tests pass. And because sometimes scripts RELY on the inconsistency.
  • if bash gives a warning, give a warning. if it is a fatal error, then fatal error.
• However, shopt --set strict_array should make ALL index of bounds a fatal error. That is more consistent and easier to explain/document. I think it's just a better experience for the user

So as another pass, we just grep IndexOutOfBounds */*.py, and make sure that if a fatal error is NOT thrown, then we throw it with strict_array

---

I can probably do this as long as the style is consistent, and it looks good so far

I think it is helping to put more stuff in bash_impl.py and have error codes

[andychu]

I noticed that bash only complains about out of bounds negative indices, but not positive

That doesn't make sense to me

$ bash -c 'a=(x y); echo ${a[5]} $((a[5])); echo status=$?'
0
status=0

$ bash -c 'a=(x y); echo ${a[-5]} $((a[-5])); echo status=$?'
bash: line 1: a: bad array subscript
bash: line 1: a: bad array subscript
0
status=0

Neither zsh or mksh do it:

andy@hoover:~/git/oilshell/oil$ zsh -c 'a=(x y); echo ${a[5]} $((a[5])); echo status=$?'
0
status=0
andy@hoover:~/git/oilshell/oil$ zsh -c 'a=(x y); echo ${a[-5]} $((a[-5])); echo status=$?'
0
status=0

I don't think it's documented - https://www.gnu.org/software/bash/manual/html_node/Arrays.html

---

I think it's fine for us to match bash because being stricter is better. But if we do shopt --set strict_array, we should disallow all negative OOB indices, not just negative ones

It also interacts with set -u I think

[andychu]

Yeah set -u is only for words, not arithmetic

$ bash -c 'set -u; a=(x y); echo ${a[5]}; echo status=$?'
bash: line 1: a[5]: unbound variable

$ bash -c 'set -u; a=(x y); echo ${a[-5]}; echo status=$?'
bash: line 1: a: bad array subscript
bash: line 1: a[-5]: unbound variable

and

$ bash -c 'set -u; a=(x y); echo $((a[5])); echo status=$?'
0
status=0

$ bash -c 'set -u; a=(x y); echo $((a[-5])); echo status=$?'
bash: line 1: a: bad array subscript
0
status=0

[akinomyoga]

Negative offset in ${a[@]:offset:length} #2184 should also be subject to strict_array check. Bash produces an empty list successfully, and the current behavior in #2184 follows Bash. However, with strict_array, one could issue a warning or an error with negative invalid index.

In addition, positive out-of-bound offset and length can also be checked by strict_array.