Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How expensive is integer-overflow trapping in C++?

lemire.me

Post reply on HN
Print view View original

61–70 of 198 posts

Re: How expensive is integer-overflow trapping in C++?

#61

Post by _hl_ »

titzer wrote: post #56
_hl_ wrote: post #14

Earlier quoted context omitted.

> each sum supposedly need 0,1ns Sub-cycle latency for an addition would be quite amazing... Nevertheless your point remains. > 100ns=0,1 ms 0.1μs, not 0.1ms

Modern superscalar processors have more than one execution unit. The latest Intel microarchitecture has 10 execution ports, which means it can theoretically execute 10 μ-ops per cycle. With a 200+ entry reorder buffer, the processor is trying hard to cram those execution units full every cycle. How successful it is depends on dynamic data dependencies and fetch/issue bandwidth. At 3ghz, to reach 0.1ns latency (on ave…

Right, but afaik only one instruction per 'hyperthread' is fetched every cycle, but I'm happy to be corrected here.

Re: How expensive is integer-overflow trapping in C++?

#62

Post by lmm »

asveikau wrote: post #8

Aborting the program on integer overflow seems so drastic. Say you do that in a server program. Then convincing it to overflow an integer somewhere (possibly somewhere where it is harmless) causes denial of service and all unrelated connections in the process die? I guess languages with support for exceptions have a more natural action for this, that could be caught somewhere in a server's processing loop to not affe…

> Aborting the program on integer overflow seems so drastic. Say you do that in a server program. Then convincing it to overflow an integer somewhere (possibly somewhere where it is harmless) causes denial of service and all unrelated connections in the process die?

If you don't abort then you probably have an arbitrary code execution vulnerability. Overflow is undefined behaviour in C++, your code is in an unanticipated state, a creative attacker can probably leverage that to do anything.

Re: How expensive is integer-overflow trapping in C++?

#63

Post by loa_in_ »

quietbritishjim wrote: post #59

> adding two large integers can result in an integer that cannot be represented in the integer type. We often refer to such error conditions as overflows. There's a subtlety here that's missed in the article: In C and C++ this is only called "overflow" for signed integers. That's because that word specifically refers to the case where the behaviour is undefined, and for unsigned integers the result is always well def…

So overflow means overflow, but underflow as well, while underflow means precision loss. What a bad case of misnomers.

Re: How expensive is integer-overflow trapping in C++?

#64

Post by MaxBarraclough »

kazinator wrote: post #48
olliej wrote: post #24

The problem with integer overflow, in the general context of UB, isn't that it's expensive to trap. The problem is that the C (and C++) specs insist on overflow being undefined behavior. Then compilers insist on abusing the UB as meaning that they get to do whatever they want. This particular case is only partially the compiler's fault, as the various specs should not be defining well specified behavior as being unde…

C compilers should assume that every bit of code is necessary. The only dead code is that which is predicated on a compile-time constant, as in: if (0) { /* safe to ptimize this away */ } Code which tests a run-time condition must always be assumed to be doing that for a reason. Just provide excellent code generation: great peephole optimizations, jump threading, instruction selection: all the "classics". Try to put…

You're essentially describing a C compiler with advanced optimisations disabled, no?

If you want improved safety and fewer footguns, the solution is to use a safer language than C, rather than to try to declaw a fundamentally unsafe language. Even MISRA C fails to guarantee the absence of undefined behaviour. (Other far more involved projects have made this a goal. [0][1]) The obvious candidates are Ada, Rust, and Zig.

It doesn't make sense to mandate the absence of serious compiler optimisations, especially for a language like C.

[0] https://github.com/zetzit/zz

[1] https://github.com/microsoft/Armada

Re: How expensive is integer-overflow trapping in C++?

#65

Post by rocqua »

himinlomax wrote: post #57

So what's the correct way to tell the C++ compiler you want integer overflow to occur in a particular spot when overflow trapping is enabled?

Use `unsigned int` instead of `int`

Overflow for signed types is undefined behavior. Hence the compiler can trap when it happens and remain standards compliant.

For unsigned types, overflow is defined behavior, and hence -ftrap will not trigger on overflow.

An interesting flip side of this is that using signed types can be a lot faster because the compiler is allowed to assume that overflow will not happen, which lets it apply more optimizations.

Re: How expensive is integer-overflow trapping in C++?

#66

Post by ChrisLomont »

saagarjha wrote: post #43
formerly_proven wrote: post #32

Earlier quoted context omitted.

Integer overflow should have been implementation-defined behavior from day one, because that's what it actually is.

Implementation defined means that the behavior is defined. This is patently not what the existing behavior of compilers in the face of integer overflow is.

Every implementation (compiler and arch combo) defines behavior as far as I know, and I’ve tested dozens of combos.

What combo does not have implementation defined behavior for C/C++ signed overflow? Are there any?

Re: How expensive is integer-overflow trapping in C++?

#67

Post by Joker_vD »

wahern wrote: post #47
alblue wrote: post #22

Earlier quoted context omitted.

This is essentially Swift’s problem on the server. If you have a service running and serving hundreds of clients, then any one of those threads can cause a trivial panic if there’s an overflow and take the entire service down. As a result, a number of use cases for swift on the server actually use heavyweight out of process threads (i.e. one process per client) so that the failure of one of them doesn’t take down the…

This reminds me of Rust unconditionally ignoring SIGPIPE. Except in this case there's a non-trivial amount of pre-existing (and even future) code that assumes a process will be terminated if it attempts to write to a closed pipe. One of Rust's selling points is ease of FFI, so it's largely irrelevant that Rust APIs wouldn't let you ignore write errors. Rust breaks the environment for libraries that rely on the behavi…

It's a bad library design to rely on a process-global setting, because one day you'll have two libraries in your project that rely on opposite values of such a global setting, and then you'll start to see very funny things.

And the library design that relies on an application it's used in being killed by the OS so that the library don't have to tidy things up after itself or to properly handle error conditions is really bad. Don't you just like when one of your random indirect dependency, thrice-removed, decides to call std::abort() just because it's tired of living?

Re: How expensive is integer-overflow trapping in C++?

#68

Post by olliej »

formerly_proven wrote: post #32
olliej wrote: post #24

The problem with integer overflow, in the general context of UB, isn't that it's expensive to trap. The problem is that the C (and C++) specs insist on overflow being undefined behavior. Then compilers insist on abusing the UB as meaning that they get to do whatever they want. This particular case is only partially the compiler's fault, as the various specs should not be defining well specified behavior as being unde…

Integer overflow should have been implementation-defined behavior from day one, because that's what it actually is.

what you're after is specified behavior. C/C++ essentially has specified, unspecified, and undefined behavior. I can't recall correct terminology.

Basically (in order), universally defined behavior, architecturally defined (under/overflow semantics, argument evaluation order, etc), things that cannot be defined (UaF, buffer under/overflows, etc).

The problem is that there is a depressing amount of undefined behavior is unnecessarily undefined. UB should be specifically limited to things that cannot have a predictable/defined behavior on any arbitrary platform - e.g. memory errors, etc.

Re: How expensive is integer-overflow trapping in C++?

#69

Post by amelius »

quietbritishjim wrote: post #59

> adding two large integers can result in an integer that cannot be represented in the integer type. We often refer to such error conditions as overflows. There's a subtlety here that's missed in the article: In C and C++ this is only called "overflow" for signed integers. That's because that word specifically refers to the case where the behaviour is undefined, and for unsigned integers the result is always well def…

We probably need different integer types to express the differences.

Perhaps whether or not we check for overflow can be encoded in the type of the integer.

Re: How expensive is integer-overflow trapping in C++?

#70

Post by gsg »

chrisseaton wrote: post #40
gsg wrote: post #29

Earlier quoted context omitted.

That still exists though? add rax, rbx/jo overflow_error is how you do overflow checking on x86-64.

That doesn’t work with a lot of arithmetic, so you have to use slower arithmetic in order to use it.

Sure, but that didn't change much between x86 and x86-64. Perhaps it got a little worse because the SIMD instructions aren't overflow check friendly.
Post reply on HN