Hacker News Reader

Comment by BeaverGoose | Hacker News Reader

Make signed overflow defined please.

I disagree, though I wouldn't mind adding a mechanism to say that you want signed overflow to be well defined.

C23 already requires 2's-complement representation for signed integer types, but signed overflow still has undefined behavior. I think that mandating 2's-complement wraparound would be a mistake.

Some instances of undefined behavior can be detected at compile time. For example, if I write

    int too_big = INT_MAX + 1;

a reasonably clever compiler can warn about it (and in fact both gcc and clang do so). If the result of INT_MAX + 1 were defined by the language to be INT_MIN, there would be no basis for such a warning.

If you evaluate n + 1 and it's possible for n to be equal to INT_MAX before the addition what do you want the result to be? Would quietly yielding INT_MIN really be useful?

Ideally, if I (accidentally) evaluate INT_MAX + 1, I'd like to be told that I've made a mistake. C doesn't have a good mechanism for doing so.

gcc has a non-standard option "-fsanitize=signed-integer-overflow" that can be used to catch signed overflow at runtime. If signed overflow yielded a well defined result, that option would be non-conforming.

> a reasonably clever compiler can warn about it (and in fact both gcc and clang do so). If the result of INT_MAX + 1 were defined by the language to be INT_MIN, there would be no basis for such a warning.

Compilers warn about perfectly well defined behaviour all the time. That's why these are warnings, not errors.

You can perfectly specify that integer overflow either traps or wraps-around (this is what Rust does). Then the flag would be conforming. You can also say it is Erroneous Behavior (a new term in C++, not yet adopted for C AFAIK) and specified to wrap-around, which will also allow the flag (and arguably models Rust behavior more closely).

Why would this help? Unsigned integer overflow is defined behavior, that causes basically the same set of bugs in practice. In a way it is worse, because at least runtime UB checkers have a reason to complain about signed integer overflow, but they won't complain about unsigned integer overflow.

If it's well defined you can actually write simple code to check for overflows (like check if the sum or product is less than the inputs) and it wont get deleted by the compiler.

Consider using the simpler code in your standard library to do this operation instead of the less scrutable version you've described here.

I would rather make unsigned overflow undefined by default and and specific defined overflow types or builtins.

Almost always, overflow is a logic error no matter what behavior the compiler defines for it so you need to make sure it doesn't happen anyway.

It would be an improvement.

However if you wan, you can already get that via a flag in pretty much any C compiler you care about.

Zig disagree with you: they even made unsigned OV undefined (in unchecked mode)

I guess yet another reason not to bother with Zig.

Or that reasonable people may disagree on when to make signed/unsigned overflow undefined: Zig didn't only make it an UB on unchecked build they also trigger an "abort on overflow" in checked build.

Make it implementation defined, if you must. But undefined is pretty sad.

Nobody forces you to use unchecked build! And some people want maximum performances, I've read that bound checking can hurt SIMDification..

If it's opt-in, it's no so bad.

(In an ideal world, which we sadly don't live in, you would statically prove that the dynamic bound checking would always succeed, and only then remove it.)

Use -fwrapv

Or -ftrapv depending on usage, both converting UB to IB. Generally letting a number overflowing and wrapping around is opening the door to let in the bad things creeping in the shadow.

Reply on news.ycombinator.com