Checking future result of arithmetic where a wraparound is undesired or undefined, is a basic skill every C programmer should know.

C is not a scripting language. If you use the tools available to you, and don't abuse the language, then it is fairly hard to cause undefined behavior.

It's not always cut-and-dried: http://blog.regehr.org/archives/1139

You really shouldn't trust every article about C on the internet. Most of them make mistakes.

If you are using gcc, you can start with the flag: -ftrapv. It does everything for you.

And with every discussion of undefined behavior in C on this site, there's bound to be some user who's telling the world how they're "holding it wrong".

I guess the best solution is to move to other languages (IIRC Ada and rust are relatively free from surprises in their UB) and let language lawyers optimize C to death (by attrition).

Ah, but then you're not writing C anymore, you're writing GCC-flavoured C.

If it helps: The author of that article, John Regehr, is a professor of computer science who spends a great deal of time studying undefined behaviour.

I don't get your point. Integer numbers have a finite valid range, and if you don't ensure that your program works only in this range, you are wrong. Whatever the compiler may do, it can't correct your error.

I guess it helps to give some context: unsigned integer overflow is defined. Some algorithms even exploit this behaviour to allow for simpler code.

But even making sure that you stay within the valid range of your integer isn't necessarily enough; you need to check that you're still within the range without going outside of it.

Many programmers assume 2s complement and would like C to rely on this.

C's automatic conversions are more problematic than signed overflow itself.

What is seemingly correct about code that causes a signed integer overflow?