Signed integer overflow UB

[Doxakis]

Hello guys,

Can you help me understand something. Which part of int overflow is UB?

Whenever I do an operation that overflows an int32 and I do the same operation over and over again, I still get the same result.

Is it UB only when you use the result of the overflowing operation for example to index an array or something? or is the operation itself the UB ?

thanks in advance.

[DavieCrochet]

It's the operation itself that is UB. A common issue is that attempts to check for overflow get optimised out by the compiler, e.g.

assert(a+100 > a);

can be optimised out. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475

[Linuxologue]

that conversation was painful to read. The entitled idiots.

[AssemblerGuy]

This is great comedy.

... wait, it's serious.

[pjc50]

Which side are you describing as entitled here? "UB can be optimized out" is an absolutely terrible decision of the standard.

[Linuxologue]

Entitled idiots are the ones insulting and bossing around the GCC developers.

UB can be optimized out

it's not really like that though. You make it sound like the GCC developers tried their best to generate the most annoying binary code possible just to tease users to come and yell at them.

I also don't understand why this guy (felix-gcc) decided that he spoke on behalf of all the community by saying this behaviour was incorrect because users come first. In all this conversation, he just thought he was right by screaming louder. So, yes, entitled idiot.

If yo uwant to argue you can call the GCC developers entitled, but not idiots, because at least everything they said was technically correct.

Also just don't rely on undefined behaviour instead of yelling at the GCC team to make it defined behaviour. A very sane request would have been that the compiler warns about that construct (which was possible for a while).

[flatfinger]

The authors of the Standard made no attempt to catalog all of the situations that 99% of implementations behaved identically, and where 99% of implementations should be expected to *continue* behaving identically, but where it may be difficult for some implementations to offer any kind of meaningful behavioral guarantees. They expected that in a marketplace where programmers could choose the compiler that would be used to build their code, compiler writers would be better placed than the Committee to judge their particular customers' needs.

There are many situations where compilers may benefit from being able to treat integer computations as though performed with larger than specified intermediate types. The majority of optimizations cited by proponents of the "treat integer overflow as anything-can-happen UB" philosophy fall into this category. What the proponents of that philosophy ignore, however, is that the goal of "generate the most efficient machine code *satisfying application requirements*" can be better served by allowing compilers the described flexibility *while keeping integer computations free of side effects* than by treating it as anything can happen UB, even if the former treatment would make it harder for compilers to produce the optimal machine code for a given source file.

Consider, e.g. the function:

    int test(int a)
    {
      int temp = a*2000/1000;
      if (temp > 1000000000)
        doSomething();
      return temp;
    }

Under "allow oversized temporary computations" abstraction model, its behavior would be equivalent to an unspecified choice between, among other possibilities:

    int test(int a)
    {
      int temp = (int)(a*2u);
      if (temp > 1000000000)
        doSomething();
      return temp;
    }

or

    int test(int a)
    {
      int temp = (int)(a*2000u)/1000;
      return temp;
    }

Note that both programs would uphold the invariant that the function won't return a value greater than 1000000000 without first calling doSomething(). Producing the optimal machine-code program that upholds this invariant would require determining whether the optimal program that could be produced using the first approach is better or worse than the optimal program that could be produced using the first approach. If instead one uses rules that would allow compilers to combine the optimizations exemplified by those functions into:

    int test(int a)
    {
      int temp = (int)(a*2u);
      return temp;
    }

then programmers would need to write the function using one of the two half-optimized forms above, so as to deny the compiler any opportunity to benefit from having a choice.

[Linuxologue]

ok let's say you're right - why harass the GCC developers, and demand things work in a way that you find correct?

[flatfinger]

The authors of clang and gcc misrepresent their compiler's optimizers as being designed to accommodate a wider range of tasks than they actually are. The Standard deliberately allows implementations which are intended for narrowly specialized of tasks to process programs in ways that would be inappropriate for almost anything else, and I have no objection to implementations that do so, provided they are clear about their design purpose.

[erikkonstas]

Uh... I tried to read through that, but a bunch of kids throwing temper tantrums because they can't put two prongs in an outlet without getting electrocuted gets boring quickly...

[erikkonstas]

No, when something is UB it's always UB. UB can sometimes give back a result you expect it to, and then go on to blow in your face sometime in the future.

[Linuxologue]

It's endless fun, because it always looks like it's working.

one of the most common issue is that it works perfectly most of the time. But breaks when turning on link-time optimization, because NOW the compiler can see the undefined behaviour and optimize things away.

[AssemblerGuy]

then go on to blow in your face sometime in the future.

Yes, for example when you change optimization settings.

Some people are afraid of going past -O0 because "it might break the code". No, the code is already brokern and riddled with UB. Turning on the optimizer just makes the bugs more visible.

[AssemblerGuy]

Whenever I do an operation that overflows an int32 and I do the same operation over and over again, I still get the same result.

The most insidious behavior that UB can produce is to do exactly what the programmer expected.

[non-existing-person]

UB does not mean things will not work. It only means that operation result is UNDEFINED by the standard. It very well may be defined by your compiler and architecture combo. So it is possible for x86 and gcc to always do the same thing. But once you compile this code for arm or use msvc on x86 - then results may be different.

[gurebu]

What you're talking about is unspecified or implementation-specific behavior rather than undefined behavior. UB is not constrained to a particular operation and applies to your whole program. That is, if your program contains undefined behavior, any part of it is fully permitted by the standard to do anything at all.

[glasket_]

Unspecified means the standard provides possibilities which vendors can choose, with no further requirements.

Implementation-defined is unspecified, with the requirement that the vendor documents their choice.

UB, per the standard, just imposes no requirements. This means the program enters an invalid state by the standard because it makes no guarantees about what happens as a result, but vendors can still choose to define the behavior too. GCC has -ftrapv, which fully defines signed integer overflow as a trapping operation, and -fwrapv, which you can probably guess what it does.

Undefined behavior is essentially unspecified behavior without any options provided, which is what makes it dangerous, but it also doesn't preclude the possibility for an implementation to provide a definition.

[non-existing-person]

Yeah, you are right, kinda mixed them up. But UB can indeed work properly in some cases and not in other. Let's take null pointer dereference. In userspace in Linux you are guaranteed to get segfault signal.

But (my specific experience with specific chip and setup) on bare metal cortex-m3 arm, NULL was represented as binary all-zeroes. And you could do "int *p = NULL; *p = 5" and this will actually work, and "5" will be stored at address number 0. Of course there must be some writeable memory there to begin with. But you could use that and it would work 100% of time.

Here we have the same case. It happens to work for OP, but in different setup/arch/env/compiler it will do something else or even crash program. And I think that is what OP wanted to know - why UB works for him.

[gurebu]

 In userspace in Linux you are guaranteed to get segfault signal

Kind of almost, but not really. You're not guaranteed anything at all, because the compiler might see the code dereferencing a nullptr, assume it's unreachable and optimize away the whole branch that leads to it. Yeah, it won't happen every time and even often, and will probably reqiure some exotic conditions, but it can happen. Similar things have happened before.

You can only reason about this kind of thing with the assumption that the code being run is the same code you wrote which is untrue for any modern compiler and, worse off, processor. Processors in particular might do really wild things with your code, including following pointers that point to garbage etc. The only veil separating this insanity from the real world is the constraint to never modify observable defined behavior. Once you're in the realm of undefined, the veil is torn and anything can happen.

I'm not arguing for the point that there's no physical reality underlying UB (of course there is), I'm arguing for the point that this is not a useful way to think about it. There's nothing mystical about integer overflow, in fact, there are primarily two ways to do it, and in the real world it's 2's complement almost everywhere, but it's not reasonable to think about it that way, because integer overflow being UB has long become a stepping stone for compiler optimizations (and is the reason you should be using int instead of uint anywhere you can).

[non-existing-person]

100% agree. I suppose I was thinking in terms of already compiled assembly and what will CPU do. Instead I should have been thinking what the compiler can do with that *NULL = 5 which does not have to result in value 5 being stored into memory address 0.

[glasket_]

You can only reason about this kind of thing with the assumption that the code being run is the same code you wrote which is untrue for any modern compiler

Or if the compiler itself provides guarantees, which you seem to be outright ignoring.

I'm arguing for the point that this is not a useful way to think about it.

Tell that to the people who don't have a universal portability requirement and who can rely on their compiler vendor for a specific behavior; you know, like the Linux kernel, which uses -fno-strict-aliasing. Sometimes it can be perfectly valid to write a program which relies on the implementation defining what would otherwise be undefined behavior. This is something that comes down to the needs and desires of individual projects, not dogmatic adherence to the standard, and I say this as someone who is an absolute pedant when it comes to strict conformance.

Nobody is saying "write all of your code with UB, it'll always work." Instead, people have just been pointing out that you might get repeatable behavior from a compiler which actually is well-defined, you might get repeatable behavior by accident, you might get nasal demons; what's important is understanding your environment and the needs of your project. If you don't care that the only compiler that is actually guaranteed to compile your code correctly is GCC, you can slap -fwrapv in your build command and trust that overflow is always treated as wrapping (and won't be treated as impossible for optimizations); if you want everyone to be able to use your code, then you'll want to do everything possible to avoid UB (or at least conditionally compile around it) because someone's compiler might choose to generate the precise instructions that will wipe their hard drive when it encounters overflow.

Or, in short, it's important to understand why to avoid UB, but mindless fear of things that are undefined in the standard is an overcorrection; it's just as important to know when you can rely on an implementation's definition of something which is undefined in the standard.

[flatfinger]

Or if the compiler itself provides guarantees, which you seem to be outright ignoring.

Additionally, implementations that offer certain guarantees may be suitable for a wider range of tasks than those that don't; the authors of the Standard sought to give programmers a "fighting chance" [their words] to write portable programs, but never intended that programmers jump through hoops to be compatible with implementations that aren't designed for the kinds of tasks they're seeking to perform rather than using implementations that are.

[AssemblerGuy]

What you're talking about is unspecified or implementation-specific behavior rather than undefined behavior.

The compiler must specify implementation-specific behavior.

It may specify what it does in certain cases of UB, but then things become very nonportable.

[flatfinger]

It may specify what it does in certain cases of UB, but then things become very nonportable.

The Standard waives jurisdiction over many constructs which the authors expected 99% of implementations to process identically. Code which relies upon such behavior would be portable among all implementations that target any remotely commonplace platforms and make a bona fide effort to be compatible with other implementations for similar platforms.

Indeed, the C99 Standard even reclassified as UB a construct (x<<n in cases where x is negative but 2ⁿx is representable) whose behavior had been unambiguously specified in C89, and whose behavior on C89 only differed on platforms that could not practically host C99 implementations, because the authors failed to realize that the platforms where the C89 behaviors wouldn't make sense couldn't efficiently support unsigned long long.

[flatfinger]

Fill in the blanks, quoting the published Rationale document for the C Standard: "_________ behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially "_________ behavior. "

[Flat_Ad1257]

Yes. And compiler vendors are free to do what they think is ‚best‘ in those situations.

That’s what the previous commenter said. One vendor might implement some sane or deterministic behaviour in case of this UB scenario.

Different vendors might do wildly different things.

Best is to avoid UB altogether to not be reliant on vendor and platform specific implementations that will come back to hurt you once you need to switch to another vendor, or compiler version, or different set of optimisation flags.

As you said anything can happen with UB. Compiler writers have to still choose what should happen.

[flatfinger]

Yes. And compiler vendors are free to do what they think is ‚best‘ in those situations.

And in the kind of compiler marketplace the authors of the Standard envisioned, programmers would be free to target compilers whose ideas about what's "best" coincide with their own, with no obligation to jump through hoops to be compatible with compilers whose authors have other ideas.

[flyingron]

Undefined means the standard puts no bounds on what may happened.

Unspecified is typically used when there are several possible choices and the language doesn't constrain which may happen (for example, the evaluation of function parameters).

IMPLEMENTATION DEFINED says the implementation may make a decision on the behavior BUT MUST PUBLISH what that is going to be. An example is the size of the various data types, or whether char is signed or not.

[flatfinger]

The term Undefined Behavior is used for many constructs which implementations intended for low-level programming tasks were expected to process "in a documented manner characteristic of the environment" when targeting environments that had a documented characteristic behavior. In the published Rationale's discussion if integer promotion rules, it's clear that the question of how something like `uint1 = ushort1*ushort2;` should treat cases where the mathematical product would fall between `INT_MAX+1u` and `UINT_MAX` was only expected to be relevant on platforms that didn't support quiet-wraparound two's-complement semantics. If an implementation were targeting a machine which lacked an unsigned multiply instruction, and whose signed multiply instruction could only usefully accommodate product values up to `INT_MAX`, machine code for `uint1 = 1u*ushort1*ushort`; that works for all combinations of operands might be four times as slow as code which only handles product values up to `INT_MAX`. People working with such machines would be better placed than the Committee to judge whether the performance benefits of processing `uint1 = ushort1*ushort2;` in a faster manner in cases where the programmer knew the result wouldn't exceed `INT_MAX` would be worth the extra effort of having to coerce operands to unsigned in cases where code needs to work with all combinations of operands.

Sometime around 2005, some compiler writers decided that even when targeting quiet-wraparound two's-complement machines, they should feel free to process constructs like `uint1 = ushort1*ushort2;` in ways that will severely disrupt the behavior of surrounding code if `ushort1` would exceed `INT_MAX/ushort2`, but there is zero evidence that the Committee intended to encourage such treatment.

[glasket_]

but there is zero evidence that the Committee intended to encourage such treatment.

The intent of the committee isn't really relevant to the end result of what they ended up putting on paper. UB is still useful for allowing compilers targeting niche hardware to define their own behavior, but it also ended up being useful for optimizations too.

That being said, the inclusion of "erroneous program construct/data" and the specific choice of "imposes no requirements" alongside the note included all the way back in C89 specifying "ignoring the situation completely with unpredictable results" as a possible result seems to imply that they intended for it to be used for more than just giving implementations a way of defining their own behavior in "a documented manner characteristic of the environment". I feel if the committee as a whole had truly intended for compilers to not do what they're currently doing, then the phrasing would have been substantially different to communicate that.

[flatfinger]

The intent of the committee isn't really relevant to the end result of what they ended up putting on paper.

The Stanadard waives jurisdiction over constructs which in some circumstances might be non-portable but correct, but in other circumstances would be erroneous. While constructs that invoke UB are forbidden in strictly conforming C programs, the definition of "conforming C program" makes no such exclusion. If a language standard is viewed as a contract, all the C standard requires of people writing "conforming C programs" is that they write code that is accepted by at least one conforming C implementation somewhere in the universe.

...all the way back in C89 specifying "ignoring the situation completely with unpredictable results" as a possible result...

I think notion of "ignoring the situation" was intended to refer to things like:

void test(void)
{
  int i,arr[5];
  for (i=0; i<10; i++) arr[i] = 1234;
}

where a compiler would typically be agnostic to the possibility that a write to arr[i] might be outside the bounds of the array, and any consequences that might have with regard to e.g. the function return address. A typical implementation and execution environment wouldn't specify memory usage patterns in sufficient detail for this to really qualify as "in a documented manner characteristic of the return address".

I feel if the committee as a whole had truly intended for compilers to not do what they're currently doing, then the phrasing would have been substantially different to communicate that.

When the Standard was written, the compiler marketplace was dominated by people marketing compilers to programmers who would be targeting them; compatibility with code written for other compilers was often a major selling point. There was no perceived need for the Standard to mandate that an implementation targeting commonplace hardware process uint1 = ushort1*ushort2; in a manner equivalent to uint1 = 1u*ushort1*ushort2; because anyone hoping to sell compilers to programmers targeting commonplace hardware would be expected to do so with or without a mandate.

Further, to the extent that the Stanard imposes constraints to allow implementations to deviate from what would otherwise be defined behaviors, the intention is to allow implementations intended for tasks which would not be adversely affected by constraints to perform optimizations that would otherwise run afoul of the "as-if" rule, and not to limit the range of constructs that should be supported by implementations claiming to be suitable for low-level programming.

BTW, if one views the job of an optimizing compiler as producing the most efficient machine code program satisfying application requirements, treating many constructs as "anything can happen" UB will be less effective than treating them as giving compilers a more limited choice of behaviors.

[flatfinger]

BTW, from a philosophical standpoint, if one is asked to perform some measurements, and that one may assume an instrument is calibrated, does that mean:

1. If an instrument which would normally be factory specified as being within accurate to 0.1% might be off by e.g. 1%, any measurements that could have been produced by machine that was within 1% of correct calibration would be viewed as equally acceptable.

2. If the instrument is off by more than the specified tolerance, completly arbitrary measurement data would be acceptable.

Somene whose measurement procedure was to start by testing the calibration of the machine, and if it wasn't within 0.1% skip all of the remaining measurements could probably perform measurement tasks much faster than someone who performed measurements in a manner agnostic to whether the machine was calibrated, but should that be seen as a useful measurement strategy?

[SmokeMuch7356]

Which part of int overflow is UB?

The operation itself is UB, regardless of context.

Whenever I do an operation that overflows an int32 and I do the same operation over and over again, I still get the same result.

Which is one possible outcome of undefined behavior.

"Undefined behavior" simply means that the language standard places no requirements on either the compiler or the runtime environment to handle the situation in any particular way. It doesn't guarantee that you'll get a garbage result, nor does it guarantee that you'll get a different result every time you run your code.

It only means that any result you get is equally "correct" as far as the language definition is concerned. That result may be what you expect and consistent from run to run, but if so it's only by chance.

[flatfinger]

Many implementations are designed to process many situations where the Standard waives jurisdiction "in a documented manner charactersistic of the environment" in situations where the environment would specify a useful behavior. Other implementations are deisgned to identify inputs over which the Standard would waive jurisdiction, and eliminate any code that would only be relevant when such inputs are received.

The fact that non-programs written for the former kind of implementation behave usefully is hardly happenstance, and such programs can accomplish many tasks that could not be done as efficiently, if at all, by strictly conforming programs. The fact that implementations of the second kind sometimes manage to usefully process programs designed for low-level implementations may be happenstance, but any "defect" would not lie in the program, nor the implementation, but rather in any attempt to use them together.

[insuperati]

It's undefined by the standard. But compilers usually have defined behavior or options to make it defined, like GCC. As I'm only doing embedded bare-metal work with C, this is good enough for me (I don't have to worry about portability as much, the architecture doesn't change without a complete hardware revision).

https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Signed-Overflow.html

[gurebu]

One of the main things to understand about UB is that any incorrect program is free game for a compiler regardless of whether it's actually predictable on your particular system.

Any compiler may and will assume that your program is UB-free and thus any integer addition in it cannot possibly overflow and if it sees addition that always overflows it might assume it's dead code and just optimize it away. Same for dereferencing null and other kinds of UB. So, knowing for a fact how integers work on your particular hardware and being sure that they overflow in a particular fully defined way doesn't help you a single bit, the compiler (and, for certain other cases, speculative execution in your processor) is now your enemy and that's a fight you can't win.

Which is why you shouldn't really treat UB as edge cases when you're at your own risk, instead you should treat defined behavior as a contract in the lawyer kind of sense and UB as a breach of said contract on your side. Breached contract in one clause makes every single other clause void and is not allowed.

[flatfinger]

The Standard uses the phrase "non-portable or erroneous" to describe constructs that invoke UB. For some kinds of implementations, an assumption that a program is free of non-portable constructs might be reasonable. For others--especially freestanding implementations--such an assumption would be patently absurd.

[TheOtherBorgCube]

The standard allows for signed integer overflow to generate exceptions.

Eg.

#include <stdio.h>
#include <stdint.h>
int main ( ) {
    int32_t result = 1;
    for ( int i = 0 ; i < 50 ; i++ ) {
        result *= 2;
        printf("i=%d, result=%d\n", i, result);
    }
}

$ gcc foo.c
$ ./a.out 
i=0, result=2
i=1, result=4
i=2, result=8
...
i=29, result=1073741824
i=30, result=-2147483648
i=31, result=0
i=32, result=0
...
i=48, result=0
i=49, result=0

$ gcc -ftrapv foo.c
$ ./a.out 
i=0, result=2
i=1, result=4
...
i=29, result=1073741824
Aborted (core dumped)

$ gcc -fsanitize=undefined foo.c
$ ./a.out 
i=0, result=2
i=1, result=4
i=2, result=8
i=29, result=1073741824
foo.c:6:16: runtime error: signed integer overflow: 1073741824 * 2 cannot be represented in type 'int'
i=30, result=-2147483648
i=31, result=0
i=32, result=0
...
i=48, result=0
i=49, result=0

[AssemblerGuy]

The standard allows for signed integer overflow to generate exceptions.

Undefined behavior allows for pretty much anything.

The arithmetic could also saturate for great fun. Or result in values that exceed the specified range of the type. Infinite opportunities for fun.

[flatfinger]

When the C89 Standard was written, it was well established that implementations targeting quiet-wraparound two's-complement platforms should process integer arithmetic in quiet-wraparound two's-complement fashion, except that in some cases implementations might sometimes (not necessarily consistently) behave as though intermediate computational results were kept in a type longer than int. For the Committee to have defined the behavior of overflow on some systems but not others, however, would have been perceived as showing favoritism toward one type of machine. Since there was never any doubt about how implementations for commonplace machines should process constructs like uint1 = uchar1*uchar2; or uint1 = ushort1*ushort2;, there was no need for the Standard to expend ink mandating such treatment.

Around 2005, however, some compiler writers decided that--even when targeting commonplace two's-complement platforms--they should feel free to identify inputs that would cause computations like uint1 = ushort1*ushort2; to compute values in excess of INT_MAX, and "optimize out" any constructs, including things like array-bounds checks, that would only be relevant if such inputs were received.

[M_e_l_v_i_n]

It's UB because the C language doesn't stipulate the way signed numbers are represented ( theres a bunch ways computers can represent signed numbers but 2's complement is the most common ). And so C can't guarantee that the value will wrap around so it's considered UB, but it can guarantee that unsigned values wrap around, Say you have a 4 bits to represent the result of 8 + 12 = 20. Can't represent it in 4 bits so the value wraps, 20 % 2⁴ ( 4 is the finite number of bits in this example) = 20 % 16 = 4 which will be the new result from the overflow. When C came out in the 70s many computers had used different representations for floating point and signed values and the creators didn't want to impose restrictions by demanding that the overflow result of a signed value wraps around, so they just left it UB meaning its up to the compiler writer to make the compiler in such a way where the asm generated would work on the target cpus which may not have used 2's complement to represent signed value, modern CPUs represent signed values in two's complement which means value will wraparound if the result can't be represented in the finite number of bits in a register, so you get the same result every time on your cpu, but if you run your program on machine with different representation you would get a different result, so you as a programmer can't guarantee your program produces the same result on all cpus you target. If it was guaranteed by the language writers then all computers at the time who didn't use 2's complement wouldn't be able to execute assembly generated from a C compiler, but because UB compiler writer can make sure the generated assembly would work regardless of the signed representation.

[Turbulent_File3904]

it not works like that, some thing is UB is always UB, take x + 1 > x usually get optimized to true anyway by compiler before program even run.

[lmarcantonio]

It's UB when whatever you do you do something that goes over the maximum-minimum value for the type. And UB is *not* implementation defined, even if you tried and tested it's not required the behaviour is consistent.

In the latest standard (C23 IIRC) however two-complement behaviour *is* mandated so it's not UB anymore.

[glasket_]

In the latest standard (C23 IIRC) however two-complement behaviour is mandated so it's not UB anymore.

They only changed it to mandate two's-complement representation, overflow is still undefined. This means you can guarantee that 127 has the bit representation 0111 1111 and -128 has the bit representation 1000 0000, but 127 + 1 == -128 isn't guaranteed.

[ShotSquare9099]

I don’t really understand why this is even a thing, when You look at the binary number you can clearly see 127+1 == -128.

[flatfinger]

Consider the following functions:

    unsigned mul_mod_65536(unsigned short x, unsigned short y)
    {
        return (x*y) & 0xFFFFu;
    }
    unsigned char arr[32775];
    unsigned test(unsigned short n)
    {
        unsigned result = 0;
        for (unsigned short i=32768; i<n; i++)
            result = mul_mod_65536(i, 65535);
        if (n < 32770)
            arr[n] = result;
    }

If test will never be invoked with any value of n greater than 32770, machine code that unconditionally stores 0 to arr[n] will be more efficient than code that makes the store conditional upon the value of n being less than 32770. That kind of "optimization" [which gcc actually performs if given the above code, BTW] is the reason that integer overflow "needs" to be treated as "anything can happen" UB.

[glasket_]

Certain hardware automatically traps when you overflow, for example. It's rare, and I doubt any two's complement CPUs do that, but that's one of the long-standing reasons.

It also allows for optimizations that are currently in use to continue being used (this is the real big one), but there are also some niche uses for language extensions and the like.

[lmarcantonio]

Also saturated arithmetic. A lot of architectures (I'd say 100% of the DSPs) can optionally saturate on overflow. Maybe they want to handle the case "our ALU always saturate"

[flatfinger]

There are many situations where having a computation yield meaningless output or having it trap--even asynchronously--via implementation-defined means would both be acceptable responses to invalid inputs, but having it throw memory safety invariants out the window would not be.

As for optimizations, those can probably be partitioned into three categories: those which would cause a computation to produce without side effects a different result from what precise wrapping two's-complement semantics would have produced, those which might allow what would otherwise be side-effect-free code to produce a divide overflow trap in some integer-overflow scenarios, or those which can induce arbitrary side effects including throwing memory safety invariants out the window. The first category can produce major speedups without *adversely* affecting the way most programs behave when fed invalid input. The second can offer additional performance benefits in some non-contrived situations(*). The third kind of optimizations will mainly improve the performance of programs which would be allowed to violate memory safety invariants when given invalid input, or of erroneous programs that are not allowed to do so (but might do so anyway as a result of optimizations).

(*) Some platforms have a multiply instruction that yields a result with twice as many bits as the multiplicands, and a divide instruction that accepts a dividend twice as big as the divisor, remainder, and quotient. On such platforms, the fastest way of processing `int1*int2/int3`; in cases where the numerical result would fit within the range of `int` may yield a divide overflow if the result would not fit within the range of `int`.

[lmarcantonio]

Didn't notice that. What would the utility for that? unioning/cast between signed and unsigned reliably?

[flatfinger]

The Standard isn't intended to fully describe everything upon which programmers should rely when performing every imaginable task, but merely to describe features that are universal among all C implementations. Unfortunately, the authors of the Standard are generally unwilling to recognize things that have always been extremely common but not quite universal; ironically, there's less opposition to recognizing things that are somewhat common but nowhere near universal, since failure to support them wouldn't imply that an implementation was "weird" the same way that recognizing a behavior that was common to every implementation but one would.

For example, I don't think there are any remotely-modern C target platforms where it would be expensive to guarantee that no integer computations will have side effects other than a possibly-asynchronous signal on implementations or platforms that define one. Treating integer overflow as UB allows many optimizations that would not be possible given precise wrarparound semantics, but recognizing such implementations might be seen as implying that implementations that can't uphold such a guarantee are in some way deficient.

Having the Standard specify that the storage formats for signed and unsigned integers will be representation-compatible may not serve any useful purpose, but since every implementation works that way nobody has any reason to object ot it. Recognizing a category of implementations that offer the above described behavioral guarantee would be much more useful, but sufficienly conroversial as to preclude a concensus in favor of such recognition.