Re: +=() can be used to set illegal indices

[Chet Ramey]

On 6/30/23 3:09 PM, Emanuele Torre wrote:
> On Fri, Jun 30, 2023 at 12:16:46PM -0400, Chet Ramey wrote:
> > > What I would have expected was something like this:
> > >
> > >     $ x=([9223372036854775805]=foo)
> > >     $ x+=( {1..5} ); echo "this won't run"
> > >     bash: some "invalid assignment" error
> > >     $ declare -p x # no value gets appended since there was an error
> >
> > No. Why wouldn't the valid assignments be accepted? If you want
> >
> > a=(1 2 3)
> >
> > to be as close as possible to
> >
> > a[0]=1
> > a[1]=2
> > a[2]=3
> >
> > you have to do it that way.

It's really more like

a=(); a[0]=1 a[1]=2 a[2]=3

and the += variant omits the initial array flush.

> Hmm, I have never noticed that behaviour to be honest.

OK, this whole discussion is pretty much way out at the margins anyway.


> I would have expected:
>
>    $ a=([1]=hi [100]=foo [-1002]=bar boo [200]=baz); echo "won't run"
>    bash: [-1002]=bar: bad array subscript
>    $ declare -p a
>    bash: declare: a: not found
>
> But it seems bash actually behaves like so:
>
>    $ a=([1]=hi [100]=foo [-1002]=bar boo [200]=baz); echo "will run"
>    bash: [-1002]=bar: bad array subscript
>    will run
>    $ declare -p a
>    declare -a a=([1]="hi" [100]="foo" [101]="boo" [200]="baz")
>
> So it simply skips and prints a warning for invalid indices, and still
> sets all the other valid indices, without triggering an error for the
> assignment; even though  a[-1002]=bar  on its own would have triggered
> an error:
>
>    $ a[1]=hi a[100]=foo a[-1002]=bar a[200]=baz; echo "won't run"
>    bash: [-1002]=bar: bad array subscript
>    $ declare -p a
>    declare -a a=([1]="hi" [100]="foo")

So how about we make the behaviors converge a little bit better: compound
assignment breaks on the first invalid assignment and makes the assignment
statement fail, which can be treated as an assignment error.


> Anyhow, if x+=() should behave similarly to  x=( ... ), I guess my
> example should work like so:
>
>    $ x=([9223372036854775805]=foo)
>    $ x+=( {1..5} ); echo "will run"
>    bash: x[-9223372036854775808]: bad array subscript
>    bash: x[-9223372036854775807]: bad array subscript
>    bash: x[-9223372036854775806]: bad array subscript
>    will run
>    $ echo "${x[@]}"
>    foo 1 2

We'll keep it breaking on the first invalid assignment, too.

I'll look at the overflow check for assignment statements. Array indices
are arithmetic expressions; the arithmetic evaluator does not perform any
checks for overflow; negative indices count backwards from the end of
the array (the highest index).

You can kind of get away with breaking on overflow with the += operator
without any explicit indices, but it's harder to reconcile that with an
explicitly-supplied index of, say, 9223372036854775808 (which evaluates
to -9223372036854775808), when the highest index is 9223372036854775807,
since max_index + 1 + subscript = 0. It's all undefined behavior, of
course, but bash has let it go in previous versions.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/