undefined | Better HN

0 pointsstephencanon6y ago0 comments

> (because of e.g. casting to unsigned and allowing the same overflow to happen anyway) only work correctly on twos-complement anyway

Unsigned arithmetic never overflows, and guarantees two's-complement behavior, because unsigned arithmetic is always carried out modulo 2^n:

> A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. (6.2.5, Types)

Doing the computation in unsigned always does the "right thing"; the thing that one needs to be careful of with this approach is the conversion of the final result back to the desired signed type (which is very easy to get subtly wrong).

0 comments

4 comments · 4 top-level

_kst_6y ago

A quibble on wording: Unsigned overflow is not "twos-complement". It gives you the same bit patterns that typical two's-complement overflow gives you, but strictly speaking two's-complement is a representation for signed values.

shawnz6y ago

Wrapping around the modulus to me is an "overflow", although maybe the spec doesn't use the word that way

2 more replies

rini176y ago

And are there standard primitives to do this correctly (signed-unsigned-signed conversion) that never invoke undefined behavior?

1 more reply

jimktrains26y ago

Interesting. I guess most/many arch's overflow flag is set when the sign bit changes and the carry flag when the result rollsover the word size.

I think most people colloquially call going A + 1 = B where B < A an overflow. Interesting. I knew they're different things, but never really thought about my word choice.

j / k navigate · click thread line to collapse