c - Is overflow of intN_t well-defined? -


in c99 there're (optional) types int8_t, int16_t , like, guaranteed have specified width , no padding bits, , represent numbers in two's complement (7.18.1.1). in 6.2.6.2 signed integer overflow mentioned footnotes 44) , 45), namely might result in trapping values in padding bits.

as intn_t don't have padding bits, , guaranteed two's complement, mean overflow doesn't generate undefined behavior? result of e.g. overflowing multiplication? addition? result reduced modulo 2^n unsigned types?

footnotes not normative. if footnote states overflow can result in trapping values in padding bits, not wrong, can see how misleading. normative text merely says behaviour undefined. placing trapping values in padding bits 1 possible consequence of undefined behaviour, not one.

so no, not mean overflow defined. it's possible operations involving intn_t/uintn_t operands overflow, , overflow result in undefined behaviour.

something int8_t = 127; ++i; has no ub. int8_t subject integral promotions, addition carried out if had written i = (int8_t) ((int) + 1);. addition not overflow, , conversion int8_t produces implementation-defined result.

something uint16_t u = 65535; u *= u; has ub on current typical implementations int has 32 sign/value bits. uint16_t subject integral promotions, multiplication carried out if had written u = (uint16_t) ((int) u * (int) u);. multiplication overflows, , behaviour undefined.

something int64_t = 9223372036854775807; ++i; has ub on implementations. addition overflows.


Comments

Popular posts from this blog

c# - Validate object ID from GET to POST -

node.js - Custom Model Validator SailsJS -

php - Find a regex to take part of Email -