On Mon, Jul 3, 2023, 23:25 Chet Ramey <chet.ra...@case.edu> wrote:
> 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.
>
im for ' run passthru ' , passthru not error
at reset last loop step
eg at assigninig next array item , or name for assoc arr ( the content
being second )
> 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.
>
looked into non finite number libs ?
gawk like .. ?
Chet
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
>
>
>
