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

191–198 of 198 posts

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

#191

Post by MaxBarraclough »

alblue wrote: post #22
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…

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…

As someone who doesn't know Swift, is there a reason it doesn't handle these errors by throwing exceptions? That approach works well for Java and .Net.

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

#192

Post by BeeOnRope »

kazinator wrote: post #186
BeeOnRope wrote: post #184

Earlier quoted context omitted.

I think people underestimate the extent to which things like "dead code" elimination matter. Basic, table stakes optimizations like constant propagation and inlining result in a ton of scenarios like the if (0) { } thing the GP mentions, even if such constructs don't explicitly appear in the code. People know what they don't like and so they logically suggest that this optimization should not occur, but it is hard to…

Dead code elimination based on iron-clad truths is important; truths like constant expressions, or expressions that evaluate true due to the range of a type or whatever. Elimination of some code block B based on some cockamamie hypothesis about some statement A being well-defined is not important.

Maybe that single optimization is not particularly important. In any case, you can turn it off with - fno-delete-null-pointer-checks, although I'd recommend against accessing null pointers in any case (you are often at the mercy of the optimizer anyway: hoping it generates non-trapping code).

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

#193

Post by ChrisLomont »

saagarjha wrote: post #183
ChrisLomont wrote: post #182

Earlier quoted context omitted.

Yes, which is exactly what I stated. My response was to “ 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.”, implying compilers didn’t have implementation defined behavior. For integer overflow, they do. You just noted this compiler chose an implementation defined behavior. And you don’t need flags for it to cho…

The compiler has not committed to a behavior, it is free to compile that code to trap the next time you try if it so wishes. "Implementation defined" means that on this particular implementation the compiler will always do the same thing.

Are you claiming if I compile the same code with the same version of the compiler on the same platform the behavior changes from compile to compile?

Demonstrate that. If not, then it is as I stated.

Certainly compilers can change behavior between versions, listed as breaking changes in the documentation.

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

#194

Post by masklinn »

MaxBarraclough wrote: post #189
masklinn wrote: post #187

Earlier quoted context omitted.

You’re you’re talking about the behaviour in C. Other langages are not C and can and do define other behaviours. Overflow is neither wrapping nor UB in Swift, it’s an error. Overflow is never UB in Rust but it might be wrapping or a panic. Overflow doesn’t exist in Python or Erlang. I think overflow is IB in Haskell. You get the point: that signed overflow is UB and unsigned wraps in C has no bearing on what other la…

This thread is about C++.

This sub-thread's starting point was literally a comment on Swift's behaviour. Unless C++ has drastically changed and now abruptly aborts on overflow.

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

#195

Post by MaxBarraclough »

masklinn wrote: post #194
MaxBarraclough wrote: post #189

Earlier quoted context omitted.

This thread is about C++.

This sub-thread's starting point was literally a comment on Swift's behaviour. Unless C++ has drastically changed and now abruptly aborts on overflow.

I think you have this confused with the subthread under alblue's comment.

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

#196

Post by formerly_proven »

ChrisLomont wrote: post #193
saagarjha wrote: post #183

Earlier quoted context omitted.

The compiler has not committed to a behavior, it is free to compile that code to trap the next time you try if it so wishes. "Implementation defined" means that on this particular implementation the compiler will always do the same thing.

Are you claiming if I compile the same code with the same version of the compiler on the same platform the behavior changes from compile to compile? Demonstrate that. If not, then it is as I stated. Certainly compilers can change behavior between versions, listed as breaking changes in the documentation.

> Are you claiming if I compile the same code with the same version of the compiler on the same platform the behavior changes from compile to compile?

Your claim ("the same code on the same platform compiled with the exact same compiler generates the same machine code") is a very weak property. Notably it doesn't mean that integer overflow behaves consistently, because it doesn't; the compiler assumes signed integers will never overflow and optimizes on that, so in one spot you might get wrapping, but in another spot the compiler removes your bounds checking, all in the same piece of code, on the same platform, compiled with the exact same compiler.

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

#197

Post by formerly_proven »

ChrisLomont wrote: post #66
saagarjha wrote: post #43

Earlier quoted context omitted.

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?

Signed integer overflow is decidedly not implementation-defined behavior in GCC, clang, recent MSVC, ...

I think you misunderstand the meaning of "implementation-defined behavior". It means the implementation chooses a particular behavior and documents it does so. For example, a compiler might choose to always wrap on signed overflow and put that in their manual. That's not what's happening.

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

#198

Post by asddubs »

jjnoakes wrote: post #135
scoutt wrote: post #126

Earlier quoted context omitted.

I guess people overreact to "undefined behavior". If your software runs always on the same platform then you can know what the behavior would be. It might also be intentional and should not crash your program. Undefined behavior is used when doing a specification for a compiler that will be used in many architectures and they cannot clearly specify what would happen on ALL architectures for a given operation, because…

> If your software runs always on the same platform then you can know what the behavior would be. This is not necessarily true, and I consider it to be a harmful misconception. I think people under-react to "undefined behavior". What you think the platform would do if you overflowed an integer using machine instructions and what your C or C++ code ends up executing can be wildly different things because C and C++ com…

yup, classic example:

https://lwn.net/Articles/278137/

Post reply on HN