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

181–190 of 198 posts

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

#181

Post by jjnoakes »

scoutt wrote: post #177
MaxBarraclough wrote: post #172

Earlier quoted context omitted.

> Especially is not something to be afraid of. Disagree. UB in C can mean your program silently going off the rails in a way that isn't possible in many other languages. UB really can manifest in bizarre and scary ways on real platforms. [0][1][2][3] If it isn't manifesting that way in your case, that's just good fortune. > I still have to find a bug or fail a test because some strange UD I should hope your safety-cr…

Again, I am not saying "go ahead and don't care about UB". I know what it is; I know what it can do. Just don't make it a big deal. You (plural) make it sound like it's impossible to build a system with C or any other laguange that allows UB, because it probably runs by coincidence . Yet the world keeps spinning and super safe flashy languages are still running on top of UB-illed OS wrote in C. > I should hope your s…

I don't think we are claiming what you say we are claiming.

I know I'm only responding because of your claim that you can know what your code does even in the face of undefined behavior.

I think this more accurately describes my position:

Code without undefined behavior can absolutely run just fine.

Code with undefined behavior is a problem waiting to happen.

Code with undefined behavior that happens to run the way you want is a happy accident. The longer it runs correctly the luckier you are.

Code in safety systems should not contain undefined behavior.

I would encourage everyone to be aware of undefined behavior, get rid of it when they know of it, and take steps to be proactive against it. For code in safety systems I would require these things if it were up to me.

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

#182

Post by ChrisLomont »

saagarjha wrote: post #180
ChrisLomont wrote: post #167

Earlier quoted context omitted.

No, both define it by default on every platform, with no flags needed. Flags allow you to force behavior one way or another. Here [1], for example, is the output from godbolt demonstrating exactly this. Note there are no flags specified, it produces valid platform specific code, and it does so for every platform listed. You can then set flags if you desire, but there is a default, as I stated. https://godbolt.org/z/j…

As you can see, the compiler has chosen an implementation that overflows in this case. It is not required to.

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 choose.

You just stated “ Neither compiler defines it unless you give it flags to specify a certain behavior”. It does define it, exactly as I said, per compiler per platform. No flags made any of them produce implementation defined output. Flags make them produce specific, cross platform behavior.

What exactly are you disputing?

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

#183

Post by saagarjha »

ChrisLomont wrote: post #182
saagarjha wrote: post #180

Earlier quoted context omitted.

As you can see, the compiler has chosen an implementation that overflows in this case. It is not required to.

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.

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

#184

Post by BeeOnRope »

nkurz wrote: post #171
BeeOnRope wrote: post #133

Earlier quoted context omitted.

The number of people who want the language and compiler implementation you are describing is vanishingly small.

Small, but vocal! I think I share kazinator's preferences here. For a C++ compiler, maybe you need dead code elimination. But for C, I'd prefer a warning accompanied by reliable execution.

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 understand the extent by which this type of optimization is helpful in other places and perhaps how it is intertwined with other useful optimizations.

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

#185

Post by pjmlp »

scoutt wrote: post #168
pjmlp wrote: post #156

Earlier quoted context omitted.

Would you feel the same way when we finally manage to get liability laws for security exploits, like we are now discussing in Germany?

If some of my systems fail, people might die. Should I still be worried for a liability?

As an professional Engineer I would be.

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

#186

Post by kazinator »

BeeOnRope wrote: post #184
nkurz wrote: post #171

Earlier quoted context omitted.

Small, but vocal! I think I share kazinator's preferences here. For a C++ compiler, maybe you need dead code elimination. But for C, I'd prefer a warning accompanied by reliable execution.

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.

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

#187

Post by masklinn »

MaxBarraclough wrote: post #55
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. Disagree. Overflowing of a signed integer type is undefined behaviour, which deserves to be taken seriously. I was surprised to see that the article doesn't mention the signed/unsigned distinction, or undefined behaviour. Overflowing of a unsigned integer type is not a problem, it's defined to wrap around, and may be done intentionally.

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 langages do.

Swift traps on overflow, regardless of signedness.

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

#188

Post by MaxBarraclough »

kazinator wrote: post #178
MaxBarraclough wrote: post #176

Earlier quoted context omitted.

> says who? Well, the modern software world. Performance is one of C's great advantages. Poorly optimising C compilers do exist, such as obscure compilers targeting obscure architectures, but much C code is written for speed. Kernels and game-engines are written in C and C++ partly for performance reasons. (Although, again, it's not as if we have to keep using C. Much safer alternatives do exist that don't have signi…

> It's the same optimisation: elimination of unreachable code. No it isn't, because in the one case, if you don't eliminate the code, it turns out to be reachable. The reason is that the logical predicate by which it was deduced to be unreachable ("the program is perfectly written and doesn't invoke undefined behavior") is not actually true. So that is to say, this code will actually terminate due to wraparound past…

So you're suggesting restricting the optimisation to trivial cases only, greatly hampering what it can do.

Again, your suggestion is imprecise. Would you want undefined behaviour eliminated from the language entirely? If yes, deep changes would need to be made. If no, there's little point, as it's still a highly unsafe language.

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

#189

Post by MaxBarraclough »

masklinn wrote: post #187
MaxBarraclough wrote: post #55

Earlier quoted context omitted.

> Aborting the program on integer overflow seems so drastic. Disagree. Overflowing of a signed integer type is undefined behaviour, which deserves to be taken seriously. I was surprised to see that the article doesn't mention the signed/unsigned distinction, or undefined behaviour. Overflowing of a unsigned integer type is not a problem, it's defined to wrap around, and may be done intentionally.

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++.

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

#190

Post by quietbritishjim »

quietbritishjim wrote: post #174
masklinn wrote: post #147

Earlier quoted context omitted.

> I don't believe Rust is anything like Swift. Do you think that by "like Swift" it just meant "languages where an overflow will result in the program aborting its execution"? That's literally the sole and entire subject of the article, what else would it mean? > If so then that was a pretty useless tautology. The wording is odd but it's a useful classification because it's an extremely uncommon behaviour. > I had as…

I don't see what your confusion is with my confusion! Something like "this thing is true about those languages where it's true" would be a totally worthless thing to say: it communicates zero actual information. It doesn't even say there actually is any one language (apart from Swift itself) that satisfies it. Why would the article include an empty statement like that? Even if it's conceivable that it does, surely it…

After all that mumbo-jumbo I now see your point (not that you're still reading...). I was reading it literally but it was just very badly written. It can be fixed up like this to have the meaning you suggested:

> In some programming languages, like Swift, an overflow will result in the program aborting its execution.

Post reply on HN