It’s checked in debug modes (overflow is a runtime error). You can explicitly use the overflow operator (+%) if you know that’s the behavior you want.

In ReleaseSafe mode, too.

Fine, but the bugs this will cause when people port code across from C or C++... probably painful.

So, to be safe people should build both Debug and Release?

It's going to be a real strategy to write your code in releasesafe, identify hot code, and mark it off as releasefast on a function by function basis

Develop in debug mode, deploy in safe release mode, and when you're absolutely sure that everything is safe, you can switch to the fast release mode.

It is also possible to selectively disable/enable safety for individual code blocks.

Alternatively, there may be unfound overflow bugs in that C/C++ code.

Worth noting that UB is also checked in ReleaseSafe mode. Related issue: https://github.com/ziglang/zig/issues/2301

Only with signed ints, since unsigned overflow is defined behaviour.

probably deploy in saferelease mode always unless you are making something like a single player video game, or that otherwise has incredible performance needs but does not deal with untrusted data.

There's slightly different looking operators if you want explicit overflow behaviour, where it's not UB.

I keep coming back to the idea that you should let the user decide. And optimizing on UB by default is always the wrong thing. Because for 99% of code performance is secondary to correctness. The compiler should only do that when requested.

A point: Benchmarks produce metrics measured in seconds. Bugs don't produce metrics you can measure but the costs are unbounded.

>I keep coming back to the idea that you should let the user decide. And optimizing on UB by default is always the wrong thing.

Aren't you contradicting yourself here?

And I do think that some UB optimizations make a lot of sense. Actually if you look at the way Rust does it, it gets rid of many UBs not by adding checks for them but by explicitly forbidding the UB condition to occur in safe code (therefore "optimizing on UB" by enforcing that the UB condition cannot happen in correct code, not by adding checks for it and slowing things down). That's why for instance pointer arithmetic is unsafe in Rust, since arbitrary pointer offsets can lead to UB.

Although I agree that there are a few C UBs that I think ought to be relaxed because they don't make a lot of sense for modern architectures though (signed overflow being the main one).

I just draw on firmware that I write for micro-controllers. Most of the code isn't in a hot path. There is probably 100 lines worth out of 50,000. That's what I mean by optimizing on UB by default at least in my case seems wrong. I'm also in the apposite situation from a web service where if a worker thread hangs you just kill it and restart it. And you can push update to the cloud.

Bringing up signed overflow. I did some tests once flipping back and forth between using a int and an unsigned int and wasn't impressed with the speed up. I've also done tests with aligned and an packed data structures and on a modern processor, also not impressed.

> Aren't you contradicting yourself here?

I don't think it's a contradiction. I think what's being said is that it's the wrong default, i.e. the special different-looking operators should be the ones with UB, not the obvious "normal"-looking ones.

Exactly. At least my experience there is code where you really care about performance and you are willing to do the distance. And then there is a lot of code where you just want it to work with no surprises.