Re: Arithmetic expression: evaluation order bug

[Steffen Nurpmeso]

Alain D D Williams wrote in
 <20221229215700.GD16276@phcomp.co.uk>:
 |On Thu, Dec 29, 2022 at 10:30:09PM +0100, Steffen Nurpmeso wrote:
 |> But then shell "operators and  their precedence, associativity,
 |> and values are the same as in the C language".  There are no
 |> sequence points.
 |
 |Order of evaluation is not the same as precedence/associativity.
 |
 |> += is right associative, and then unwound.
 |
 |> (For C, they do it all right,
 |
 |There is not a 'right' since the expression is undefined as it breaks
 |sequencing rules. You have a notion of 'right' that might well be what \
 |happens
 |(with compilers that you have tested) but you are not allowed to make that
 |assumption.
 |
 |> only clang warns on sequencing when tested.
 |
 |Ah: so only clang gives the warning that the others should probably give.

By default.

 |> But yes, i do "hate" ISO/IEC JTC1/SC22/WG14, N925, "A formal model of
 |> sequence points and related issues", Clive Feather, from Y2K (my \
 |> version),
 |> and if only for such cases like the above.
 |
 |Standards are not written to be "liked". They describe how a compiler \
 |should
 |work which includes things where the compiler writer can do as they \
 |please if
 |they think that they can generate faster/smaller/... machine code.
 |
 |> Or the x=++x shown in the committee document (for exactly that reason i
 |> presume: an "easy" formal formula to make it work, even if human \
 |> logic gives
 |> you the green light).)
 |
 |What does "human logic" mean ?
 |
 |Anyway: back to what the shell should be doing. You cannot put a ';' \
 |into (( ))
 |as a sequence point, but the manual does say:
 |
 |"Sub-expressions in parentheses are evaluated first and may override the
 |precedence rules above"
 |
 |So use sub-expressions to 'evaluate first' so you should prolly rewrite:
 |
 |(( i += j += i += i ))
 |
 |as:
 |
 |(( i += (j += (i += i)) ))
 |
 |Regards

Not me!!  Bash does it right for x=++x, where is your sequence
point?  dash for example evaluates the construct also in the way
one would expect (which i would glue to "human logic").
Also, i would argue, you cannot put your finger on ISO C sequence
points and then keep the way bash evaluates integers, this is
comme ci comme ça.

But regardless, i still think it is a bug, that i hereby have
reported, army troopers aside.
I _will_ keep my evaluator the way it is, maybe someone should
report a dash bug if she or he thinks otherwise.  I have not
looked at other shells (i would hope those which support the
operator keep human logic (!) happy).

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)