upvote

points

by Joker_vD3 hours ago |
comments
upvoteby dgrunwald2 hours ago|
next
[-]
> 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.

reply
upvoteby nayuki55 minutes ago|
parent|
next
[-]
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).
reply
upvoteby Joker_vD46 minutes ago|
parent|
[-]
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).
reply
upvoteby nayuki29 minutes ago|
parent|
[-]
> 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.

reply
upvoteby Joker_vD50 minutes ago|
parent|
prev|
[-]
> 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.

reply
upvoteby nayuki31 minutes ago|
parent|
[-]
> 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
upvoteby magicalhippo2 hours ago|
prev|
next
[-]
> I'm fairly certain that a) IEEE does not mandate the in-memory representation,

That's not how I interpret section 3.2 in the standard[1]. Figure 1 seems quite explicit in how a single and a double should be encoded. The section on extended values specify they can be encoded in an implementation-depended manner, which makes the case stronger IMO.

edit: I note that in the 2008 revision[2], it's more explicitly mentioned that the specified encoding is a binary interchange format. So that's a lot more specific than the original.

[1]: https://pub.sergev.org/doc/ieee754-1985.pdf

[2]: https://pub.sergev.org/doc/ieee754-2008.pdf

reply
upvoteby Joker_vD57 minutes ago|
parent|
[-]
It only talks about MSBs and LSBs. It does not specify whether the LSB of the value as the whole resides in the first byte of the memory representation or in the fourth/eighth.

And of course, if you accept the network byte order as the one intended for the interchange, then IEEE-754 mandates big-endian encoding.

reply
upvoteby sparkie54 minutes ago|
parent|
[-]
Maybe you are talking past grandparent, but I think they meant "it's safe to assume float and double are IEEE-754," which is not mandated by the C standard.
reply
upvoteby drysine2 hours ago|
prev|
[-]
>> platforms have very long agreed on twos-complement for negative integers. This even made it into the standard at some point, I believe.

>Only in C23. It was explicitly rejected for C++ 23 (and C++ 26 too, I believe).

It was added in C++20[0], see the note[1] "This is also known as two's complement representation".

[0] https://timsong-cpp.github.io/cppwp/n4868/basic.fundamental#...

[1] https://timsong-cpp.github.io/cppwp/n4868/basic.fundamental#...

reply