On 31/05/2026 18:46, James Kuyper wrote:...On 2026-05-31 11:35, David Brown wrote:
If an implementation provides additional semantics to signed integer>
arithmetic, such as saturating or trapping overflow, then signed integer
arithmetic operations are no longer associative. But normal C undefined
behaviour on overflow is fully associative (as is wrapping semantics,
for addition, subtraction and multiplication).
I don't follow that. I believe that overflow is guaranteed for (5 +
INT_MAX) + INT_MIN, and completely avoided by 5 + (INT_MAX + INT_MIN),
which differ only by association. Are you saying they both have the
same chance of overflowing?
No - I see now what you are saying. Overflow is never guaranteed to do
anything, including to exist, because it is UB. So the compiler can
I only meant that overflow was guaranteed, and that the behavior was
therefore guaranteed to be undefined. I didn't mean to imply that any
particular behavior was guaranteed.
happily treat "(5 + INT_MAX) + INT_MIN" as though you had written "5 +
(INT_MAX + INT_MIN)". It can freely re-arrange an expression like this
that has a potential overflow into one without risk of overflow, as long
as the same results are given for all values that do not overflow. (The
overflow is not part of the observable behaviour.) But it cannot
re-arrange the other way unless it knows that intermediary overflows
have no effect. (And the compiler usually does know this.)
That's what I was mainly concerned about - if I've carefully arranged to
make sure that overflow is impossible, I'd be rather upset by a compiler
which, because "normal C undefined behaviour on overflow is fully
associative", rearranges the associations in my code to make overflow
possible. I interpreted that comment as meaning that "whether or not the
behavior is undefined is fully associative". I guess that what you
actually meant was "if the behavior is undefined, the compiler is free
to rearrange the associations".
Les messages affichés proviennent d'usenet.