Hacker News Reader

> If UB was instead defined to trap, most optimizations that are made possible by UB would still be possible, but without the footgun part.

That's not true. Suddenly, almost every single signed integer operation on a machine with different hardware integer widths than the language implementation requires branching to check for overflow.

View on HN

You could also take a measured approach and, like rust, just define signed overflow to wrap. UB and its current interpretation is not worth whatever small sliver of performance the current implementation of LLVM appears to give you.

I don't agree that this is measured. It has a few big problems.

1. Basically no developer actually wants it to wrap. This is almost certainly a logical bug that just pushes the problem a few statements further into the program.

2. Defining it to wrap means that you need software checks for architectures that don't support hardware wrapping on the same width as the integer type. This means that all programs get slower when targeting these architectures. This isn't a "sliver of performance". It is a software branch at almost every integer operation. This approach is not especially well loved in the C/C++ communities.

Reply on news.ycombinator.com