bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Arithmetic expression: evaluation order bug


From: Robert Elz
Subject: Re: Arithmetic expression: evaluation order bug
Date: Fri, 30 Dec 2022 16:23:23 +0700

    Date:        Thu, 29 Dec 2022 21:57:00 +0000
    From:        Alain D D Williams <addw@phcomp.co.uk>
    Message-ID:  <20221229215700.GD16276@phcomp.co.uk>

  | So use sub-expressions to 'evaluate first' so you should prolly rewrite:
  |
  | (( i += j += i += i ))
  |
  | as:
  |
  | (( i += (j += (i += i)) ))


That's not likely to make any difference, and in fact, doesn't in bash.
Parentheses affect operator precedence, and associativity, in practice
they're just used to build to appropriate evaluation tree, once that
exists, they no longer exist (the expression evaluator never sees a
parenthesis).

The way to make this work is to insert sequence points, of which there
is only one which is plausible in shell arithmetic expressions, and even
that isn't required to exist by POSIX.

   $(( i += i, j += i, i += j ))

for that expression (and similar for the other one) is defined in C, and
so should be implemented the same way by all shells, and is, at least by
those which actually implement the ',' operator (which excludes dash,
the FreeBSD sh, and yash).   Affected people might want to apply some
pressure to the implementors of those to add the required support, it is
trivial to do (just multiple expressions, evaluated one after another).

For what it is worth, I tested a bunch of shells with the original
expressions, all ksh variants, bosh, and bash evaluate the original
expressions the bash way, all ash variants, plus yash and zsh implement
it the dash way.   Neither is incorrect.

kre




reply via email to

[Prev in Thread] Current Thread [Next in Thread]