My belief is that this was done so compilers could employ optimizations
that did not have to consider or maintain implementation-specific
behavior when integers would wrap. I don't agree with this, I think 2's
complement behavior on integers as an implementation-specific behavior
can be well-specified, and well-understood, machine by machine, but I
think this is one of the places where compilers and benchmarks conspire
to subvert the obvious and change the language to "language-legally"
allow optimizations that can break the used-to-be-expected 2's
complement implementation-specific behavior.
It isn't just about optimizations.
Unsigned math in C is well defined here. The problem is that its wrapping behavior is almost (but not) always a bug. Because of that, for instance, one cannot write a no-false-positive sanitizer to catch this because it cannot tell the difference between an accidental bug and a deliberate use. This is a well-defined case with a very reasonable definition which most of the time leads to bugs.
There are times folks want the wrapping behavior. There are times folks want saturating behavior. There are times folks want such code to error out. There are times folks want the optimizing behavior because their code doesn't go anywhere near wrapping.
Ultimately, one needs different functions for the different behaviors, but if you only have one spelling for that operation, you can only get one behavior. A given type has to pick one of the above behaviors for a given spelling of an operation.
You can, of course, disagree with what C picked here (many do), but it is unlikely to change in the future.
- Performance concerns, whereby defining the behavior prevents optimizers from assuming that overflow never occurs;
- Implementation leeway for tools such as sanitizers;
- Data from Google suggesting that over 90% of all overflow is a bug, and defining wrapping behavior would not have solved the bug.
Fun fact: in C++ std::atomic<int> does wrap, so you can actually get the behavior you want. I haven't looked to see if that is also true using C's _Atomic type qualifier.
Full disclosure: I am on the WG21 (C++) Committee and am starting to participate on the WG14 (C) Committee.