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. > 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 -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h>
