Hacker News Reader

Comment by dgrunwald | Hacker News Reader

> ILP64 (wherein int is 64 bits) exists. It's not very popular, but it exists; e.g. ICC supports it.

ILP64 is problematic for existing code: there is lots of stuff like hashcode computations using uint32_t with multiplications, relying on the C standard guaranteeing wraparound for unsigned overflows. But with 64-bit int, uint32_t will promote to a signed int, and overflows will thus be undefined behavior. This problem already exists with uint16_t multiplications on current architectures, but moving the problem to uint32_t will cause trouble for a lot of existing code that thought using fixed-size types like uint32_t would be safe.

View on HN

Thank you for being one of the few people who understands that in C/C++, `unsigned OP unsigned` can have each operand be promoted to a signed integer and then have the operation overflow and cause undefined behavior.

I chose to deal with this problem by doing a "pointless" operation to force a promotion to at least unsigned int. For example:

    uint16_t x = 0xFFFF;
    uint16_t y = 0xFFFF;
    uint16_t z = (uint16_t)((x + 0U) * (y + 0U));

This piece of code will work on any machine, such as: (uint16_t = unsigned short = 16 bits, uint32_t = unsigned int = 32 bits); (uint16_t = unsigned short = unsigned int = 16 bits, uint32_t = unsigned long = 32 bits).

But the result is 1, whether you calculate it as 16-by-16 unsigned multiplication (you get 0xFFFE0001 truncated down to 1), or 32-by-32 signed (you multiply -1 by -1 and get 1, with no overflow).

> 32-by-32 signed (you multiply -1 by -1 and get 1, with no overflow)

Wrong. You mentally casted each operand to int16_t before subsequently casting to int32_t. The first step is unjustified.

The correct calculation according to the C standard is: (int32_t)0xFFFF * (int32_t)0xFFFF, which definitely overflows.

> You mentally casted each operand to int16_t before subsequently casting to int32_t. The first step is unjustified.

That's horrifying. Why were unsigned shorts made to convert to signed ints by zero-extension, again?

Because the language rules say so, and I'm not the one who made the rules. https://en.cppreference.com/c/language/conversion#Integer_pr...

> Integer promotion is the implicit conversion of a value of any integer type with rank less or equal to rank of int or of {a bit-field of type _Bool(until C23)/bool(since C23), int, signed int, unsigned int}, to the value of type int or unsigned int.

> If int can represent the entire range of values of the original type (or the range of values of the original bit-field), the value is converted to type int. Otherwise the value is converted to unsigned int.

The fact that the C/C++ integer conversion rules have these unintuitive footguns is why I made it a talking point.

One reason is that the language didn't originally intend for UB to be so broad. They probably expected that each value would be loaded into an int-sized register, and the calculation would then be performed on two int-sized registers with overflow handled in a platform-dependent but generally sane manner (not time travel).

Yeah, reading the rationale in the standard itself, it's is kinda obvious that they didn't consider potential UB at all: when talking about "questionable signedness" they only mention division/remainder and comparisons as being possibly affected, but not addition/multiplication (due to overflow), and comparisons behaving mostly expectedly (for some value of "expectedly") is the main selling point. But comparing signed and unsigned values without actual thought and explicit cast is almost always a bug anyway! And we had the warnings for that for, like, forever.

Makes me wonder how ergonomic would a language with actually correct signatures for the arithmetic operators be.

    +<S, M, N>: int<S, M> × int<S, N> → int<S, max(M, N)+1> // alternatively int<S, max(M, N)> × bool
    -<S, M, N>: int<S, M> × int<S, N> → int<signed, max(M, N)+1> // alternatively int<signed, max(M, N)> × bool
    *<S, M, N>: int<S, M> × int<S, N> → int<S, M+N>
    /<S, M, N>: int<S, M> × int<S, N> → int<S, M>
    %<S, M, N>: int<S, M> × int<S, N> → int<S, N>

> stuff like hashcode computations using uint32_t with multiplications, relying on the C standard guaranteeing wraparound for unsigned overflows. But with 64-bit int, uint32_t will promote to a signed int, and overflows will thus be undefined behavior.

Yeah, except that multiplying two 32-bit values, recast as 64-bit signed integers, will not overflow. Even adding another 32-bit value to this product will not overflow. Throw in the final cast to uint32_t to throw away the upper sign bits, and you get the identical result.

> multiplying two 32-bit values, recast as 64-bit signed integers, will not overflow

Factually wrong. Consider: (int64_t)0xFFFFFFFF * (int64_t)0xFFFFFFFF. It definitely overflows.

Reply on news.ycombinator.com