<limits>: fix traps for integers

[AlexGuteniev]

ARM64 coverage being added in #5815 drawn my attention to that numeric_limit has traps, and it is apparently defined incorrectly for some architectures.

🪤 What are traps?

See https://en.cppreference.com/w/cpp/types/numeric_limits/traps.html

traps should be true if there's an operation on a value of that type that traps.

For integers, it is zero division, it usually traps, but still does not trap for certain compiler/platform combinations. Sometimes it also happens with signed overflow on division. See below.

Hypothetically, I imagine that other signed overflows, like incrementing int containing INT_MAX, may trap, but I'm not aware if any hardware behaves like this, at least, not our target platforms.

We all know that bools are integers, but they are surprisingly exempt from zero division trap: when you divide by false, you actually divide by integer zero, so it is not bool value that traps 😕. Oh, and bool has non-value representations, but they do not trap for us either.

For the same reason, other promoted integers don't trap.

Floats normally don't trap. You need to both compile with /fp:except and enable these exceptions to make them trap. The trait reflects the state after program starts, so enabling by setting control word does not count.

Overall that part of the traits doesn't seem to be terribly useful feature. For platform-agnostic code, the information "it is trap" is not useful, it does not tell where is the trap and what is the trap. And for platform-specific code, you can know the behavior of exact platforms specifically without querying the trait.

➗ Integer division traps

On x64 and x86,, integer zero division triggers some interrupt, ultimately resulting in STATUS_INTEGER_DIVIDE_BY_ZERO (0xC0000094) structured exception.

On Arm64 zero integer division results in having zero at destination, and no trap.

However, MSVC inserts check for zero and brk instruction to get into the same trap 🐶.

clang-cl does not implement this behavior, and does not trap on Arm64.

INT_MIN / -1 division would also trap on x64 and x86. The exception code is STATUS_INTEGER_OVERFLOW (0xC0000095).

This integer division overflow does not trap on Arm64: MSVC does not insert any checks for that.

⚙️ Product code fix

We change the value of traps for all integers except bools and other promoted ones on all supported architectures.

Except for Clang on Arm64, where we keep it false.

✔️ Coverage

The runtime test approach was rejected, as it needs UB to perform the actual behavior test.
So the test checks for the assumed behavior on current hardware and compiler.
It errors out on an unknown hardware.

This libc++ test still needs some fixes.

I have not checked ARM64 EC, but according to the 👮‍♂️ two policemen theorem 👮‍♀️, if it traps on x64, and traps on Arm64, then on Arm64 EC that is between both of them it also traps. And I expect from Clang to behave naturally and don't trap there.

🎃 Horror

This might be a mess when we link Clang and MSVC objects together, we define the same variable differently. On the other hand, we also mix behaviors in this case. The variable is constexpr and hence very inline, so the definition should not matter, it is expected to inline to query site even in /Od.

[frederick-vs-ja]

We all know that bools are integers, but they are surprisingly exempt from zero division trap: when you divide by false, you actually divide by integer zero, so it is not bool value that traps 😕. Oh, and bool has non-value representations, but they do not trap for us either.

Oh, however, this is arguably true for all non-promoted integer types. Due to usual arithmetic conversions, no arithmetic operation on char, short, etc. is actually performed because the operands are converted to int first. I guess an LWG issue is wanted.

[AlexGuteniev]

Oh, however, this is arguably true for all non-promoted integer types.

Yes, @Alcaro mentioned that in Discord, and captured that in llvm/llvm-project#166053

You can argue that division by false promotes to int, therefore it's not an operation on bool that traps, but if so, char is wrong.

---

I guess an LWG issue is wanted.

You can try.
What I'd actually want here after thinking about this all is this trait deprecation and removal.

[frederick-vs-ja]

Ah, I found that there's already LWG-554 which is closed as NAD. So perhaps we should make numeric_limits<I>::traps false for all non-promoted integer types.

[AlexGuteniev]

Thanks, I'll mention LWG-554 in the test.

So perhaps we should make numeric_limits<I>::traps false for all non-promoted integer types.

I'm not sure. On one hand, the promotion happens. On the other, one can say that zero value does not change when it can be represented, whereas false is converted to zero.

[Alcaro]

Let's make this mess even worse. Let's add two more interpretations of this property.

• True for int, char and bool, because (T)1 / (T)0 traps (except Clang on ARM)
• True for int and char, false for bool; the above, but (bool)1 is true, not 1
• True for int, false for char and bool, because no operations exist on char or bool, it insta-promotes to int

• False for int/char/bool, because that property is not about operations - it's about values, and more specifically about trap representations. Two's complement hardware doesn't have trap representations on integer types.
• False for int/char, true for bool; the above, but 'trap representation' doesn't mean crash - it means bit pattern that's instant UB if memcpy'd into that type

I feel the last one is slightly - slightly - more intuitive than the other four, but it's explicitly banhammered by LWG-554.

I'm starting to suspect that the only winning move is not to play.

[frederick-vs-ja]

• False for int/char/bool, because that property is not about operations - it's about values, and more specifically about trap representations. Two's complement hardware doesn't have trap representations on integer types.
• False for int/char, true for bool; the above, but 'trap representation' doesn't mean crash - it means bit pattern that's instant UB if memcpy'd into that type

I'd say the term "trap representation" is questionable. WG14-N2861 corrected it to "non-value representation", which should have clarified that such representations are not about values. CWG-2899 also clarified similar conditions in C++.

---

Oh, memcpying into that type should be fine. Only lvalue-to-rvalue conversion reading that representation has UB. The last interpretation seems meaningful for all trivially copyable types, but it's unrelated to arithmetic operations.

[StephanTLavavej]

Thanks for figuring all this stuff out and my apologies for how long it took to get to this! 😸

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo. Please notify me if any further changes are pushed, otherwise no action is required.

[StephanTLavavej]

Thanks, Admiral Ackbar! 🐠 🧑‍🚀 💥