This seems like a situation where dropping to assembly to perform the addition and testing the flag makes sense. GCC has a mechanism for inline assembly where you list the variables you read from, you write to, and registers you modify and the optimizer plays nice with you. You could provide it as a function to use instead of doing the addition in C.
That said in modern clang and gcc you can (and should) use the overflow builtins which are all essentially:
Bool __builtin_[operation]_overflow(type a, type b, type* out)
if(overflowoperation(x,y,&out)) ...
Produces the platform branch on overflow instructions.
Eh, the undefined nature of signed overflow in C is a bit of a red herring. The most common overflow bug in practice is actually 100% well-defined and still 100% wrong: multiplying two numbers to feed into a malloc.
In practice, the undefined signed overflow really only comes into play when you're trying to explicitly check for overflow by doing the operation and then seeing if it overflowed. But, as you mention, compilers give you bultins to do this kind of checked overflow which is quite frankly a much easier way to solve the problem, especially since it's more likely to actually get matched to using hardware flag bits to check for overflow.
That is not an accurate or fair assessment.
However signed integer overflow being undefined behavior is a bit over the top given modern hardware. I'd like to see the C standard adopt a policy of wrapping for signed overflow, then either add new operators or functions for trapping behavior.
Most reasonable hardware has the instructions to trap or branch if add/sub/mul/div overflows or underflows so the checks are very cheap. Unlike the early days, in this day if C made it part of the standard processor manufacturers would simply stop selling CPUs without those features. Same goes for two's-compliment integer representations. They already did the same for 8-bit char/byte; other sizes are no longer supported.
Obviously there is signed integer overflow, which has resulted in numerous security flaws for questionable performance gains.
Then there are other fun things, like technically it is UB for bzero to skip padding bytes in a struct (because that is UB), which means bzero(&somestruct, siseof(somestruct)) is not technically guaranteed to clear all of the struct, so I hope there’s not any secrets in left over memory.
Punning through unions is well-defined behavior in C99 and C11. In C++11 and newer, it's questionable, but it works in practice.
And that is effectively a bug in that standard, says Linus, and I agree with him.
https://lkml.org/lkml/2018/6/5/769
"I've said this before, and I'll say it again: a standards paper is just so much toilet paper when it conflicts with reality."
Sadly, the compiler maintainers at some points of time managed to push the real "breaking" changes through (for other UB cases). It seems that the "language lawyerism" is "easier" than the expected approach of the responsible engineers.
I suppose union based type punning makes the intent a little clearer (vis a vis memcpy) but that's a weak argument at best.
How much more explicit can you get than a memcpy?
Memcpy is a cost. Do it only when you actually need a copy.
Aliasing queries in the compiler basically work on a tiered system. There's a simple aliasing pass that first checks for really obvious alias information (such as, it's the same pointer, it's a bitcast of the pointer, it's a simple arithmetic expression of the same pointer), possibly some more advanced Andersen's-style alias passes, and only finally is there a last-ditch strict-aliasing based pass.
If you take the address of a float and cast that to an integer pointer to get at the bits of the float (and don't let either pointer escape the function), it will work, even with "abusive" compilers that have aggressive optimization turned on, even if you modify the lvalue in the intervening code. It's literally more work to make the compiler not realize that the two pointers alias, and there's no benefit to pessimizing a trivial query, so I would be shocked if any compiler actually miscompiled that code.
The definition of UB would allow a type punned union on the stack for instance to be treated as logically a struct - eg changes to the float value would not impact the integer value. While I agree that would not happen in practice today there is no reason it has to continue to work.
The fact that compilers already make sane decisions regarding some UB - evaluation order of parameters used to be unspecified and gcc at least would change evaluation order depending of optimisation level, but all compilers have realized that just insane and so left to right evaluation. Similarly bzero will initialise padding bytes in a struct even though that is technically UB, so could technically be skipped.
Sorry for run on horror sentences I’m typing on my phone :)
It's easy to write, but not so easy to optimize the performance.
Overflow checking creates a dependency in between operations and requires the emission of instructions that didn't have to be there before.
i += 1 <branch if overflow> i += 1 <etc>
Means that you are executing more than twice the number of instructions and are getting further behind on the dependency chain each iteration. Eventually, your branch subsystem is completely overwhelmed by a branch that is taken effectively never.