Re: Arithmetic expression: evaluation order bug

[Alain D D Williams]

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>