3 ms·
But `uint16_t + uint16_t` has exactly the same problem -- if it's a typedef for `unsigned short`, there will be promotion to either `int` or `unsigned int`. A
by ynik 7y ago
But `uint16_t + uint16_t` has exactly the same problem -- if it's a typedef for `unsigned short`, there will be promotion to either `int` or `unsigned int`.
A multiplication `uint16_t * uint16_t` can still cause an overflow after promotion to signed int, which is undefined behavior!
So "unsigned types wrap around" doesn't apply to `uintN_t`, because you can never know for sure whether those types are "smaller than int" and thus get promoted to signed types when you do any arithmetic.
Of course, in practice this just means: every C and C++ program relies on tons of implementation-defined behavior. A `sizeof(int)` greater than 32-bits would break most code in existence (e.g. hash code computations using `uint32_t`).
- vardump 7y ago> A multiplication `uint16_t * uint16_t` can still cause an overflow after promotion to signed int Last time similar thing bit me was when the platform had 16-bit int... so just adding two int16_t can very well cause int overflow.
- wahern 7y ago> because you can never know for sure whether those types are "smaller than int" and thus get promoted to signed types when you do any arithmetic You can deduce the width (number of sign + value bits) of the standard integer types from their limits (e.g. INT_MAX, INT_MIN, etc). The problem has been that this is non-trivial if not impossible to do from the preprocessor. The next C standard will include width constants (e.g. INT_WIDTH) for the standard integer types.
- loeg 7y agoIn practice programs on these weird large-int machines would just use `-fwrapv` and move on.