Alain D D Williams wrote in <20221229215700.gd16...@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)
