Some DACs and ADCs have “saturating” math: INT_MAX + 1 == INT_MAX. This is because rollover would cause glitching in the audio stream (switching from near INT_MAX to near -INT_MAX and back), whereas sticking at INT_MAX produces a much less noticeable glitch and does not run a risk of harming analog hardware being fed the signal.
As vyodaiken said, some architectures can trap on signed overflow. I know the VAX can do that (there’s a flag in the CPU you can set to enable that) and the MIPS (by using the add instruction, but every C compiler I ever used on the MIPS used the addu version which doesn’t trap).
The problem is that most (and by “most” I mean “over 99 44/100% of programmers” but I could be off by as much a a percent or two) has never encountered or will never encounter such a system (much like most programmers will never encounter a 1’s complement integer CPU, and no programmer will ever encounter a signed-magnitude integer CPU [1] yet the C standard still makes allowances for those).
The other problem is that C doesn’t mandate a set size for integers. On a 16-bit CPU, yes, overflow is probably going to happen. On a 32-bit system, less likely (unless you are working with large data sets) and almost not at all on a 64-bit system (unless it’s a real bug and yes, this is a gut feeling I have).
Having read up on this mess, I’m slowly coming the conclusion that the following routine:
int add(int a,int b)
{
return a + b;
}
Invokes undefined behavior because it could overflow—to be really sure, you need to do:
int add(int a,int b)
{
if ((a > 0) && (b > 0))
{
if (INT_MAX - a > b) abort();
if (INT_MAX - b > b) abort();
}
else if ((a < 0) && (b < 0))
{
if (INT_MIN - a < b) abort();
if (INT_MIN - b < a) abort();
}
return a + b;
}
And here, I’m only half-joking. Sometimes, I really miss the carry bit from assembly.
[1] I’m certain on the signed-magnitude bit because as far as I can tell, only one machine was ever commercially available, and that was back in the 50s!
In some architectures signed overflow can be set to or must cause traps. In those cases you’d want some signal. It’s an actual error to overflow. there may be other methods. It would be nice if the overflow flag was visible to C code so you could do for(int i=0; nooverflow() && i < N; i++) ….
[Comment removed by author]
Some DACs and ADCs have “saturating” math:
INT_MAX + 1 == INT_MAX. This is because rollover would cause glitching in the audio stream (switching from nearINT_MAXto near-INT_MAXand back), whereas sticking atINT_MAXproduces a much less noticeable glitch and does not run a risk of harming analog hardware being fed the signal.As vyodaiken said, some architectures can trap on signed overflow. I know the VAX can do that (there’s a flag in the CPU you can set to enable that) and the MIPS (by using the add instruction, but every C compiler I ever used on the MIPS used the addu version which doesn’t trap).
The problem is that most (and by “most” I mean “over 99 44/100% of programmers” but I could be off by as much a a percent or two) has never encountered or will never encounter such a system (much like most programmers will never encounter a 1’s complement integer CPU, and no programmer will ever encounter a signed-magnitude integer CPU [1] yet the C standard still makes allowances for those).
The other problem is that C doesn’t mandate a set size for integers. On a 16-bit CPU, yes, overflow is probably going to happen. On a 32-bit system, less likely (unless you are working with large data sets) and almost not at all on a 64-bit system (unless it’s a real bug and yes, this is a gut feeling I have).
Having read up on this mess, I’m slowly coming the conclusion that the following routine:
Invokes undefined behavior because it could overflow—to be really sure, you need to do:
And here, I’m only half-joking. Sometimes, I really miss the carry bit from assembly.
[1] I’m certain on the signed-magnitude bit because as far as I can tell, only one machine was ever commercially available, and that was back in the 50s!
I think you are right. If you have
I believe the compiler is permitted to replace your program with ransomware according to the current standard and interpretation.
In some architectures signed overflow can be set to or must cause traps. In those cases you’d want some signal. It’s an actual error to overflow. there may be other methods. It would be nice if the overflow flag was visible to C code so you could do for(int i=0; nooverflow() && i < N; i++) ….
Some platforms trap overflows in hardware, resulting in program termination/signals/exceptions/whatever.