Hacker News Reader

Comment by torstenvl | Hacker News Reader

Wait so we're going to give up -fwrapv (a UB mitigation) for the explicit purpose of introducing more undefined behavior?

I don't see any way this change wouldn't lead to an enormous number of bugs, all for the (dubious) goal of having the range of signed integers be symmetrical.

View on HN

-fwrapv is an UB mitigation that often just hides bugs and consequently creates more UB down the road, in places where it is less easy to diagnose. For example identifying an integer overflow is quite easy but placing bounds checks on all allocations in an ABI-preserving way is much more difficult.

I think the idea is that overflowing would be a guaranteed trap of some kind, i.e. defined behavior.

You don't have to introduce more undefined behaviour. A trap could be very defined behaviour.

No. What? No. A trap is by definition undefined behavior.

"Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undeﬁned. If such a representation is produced by a side effect that modiﬁes all or any part of the object by an lvalue expression that does not have character type, the behavior is undeﬁned."

I think the idea would be to redefine "the object type" to make the trap value valid -- and to define the result of all operators on the trap value in some sensible way (similar to non-signalling NaNs in IEEE-754 floating point), so that, e.g., adding the trap value and any number produces the trap value again.

It is not possible for a trap representation to be made valid. A trap representation is one where getting it or setting it, other than as a raw byte, is undefined behavior.

Section 6.2.6.1, paragraph 5, of C99, C11, C17, and—with a terminology change—the final draft of C23 are crystal clear on this.

I think you may be too hung up on the C(?) definition of trap representation.

Clearly the OP suggestion isn't viable for default C integers anyway, and whichever language OP's suggestion is applied to is free to define the behavior of trap representations.

A trap is something the programmer should have to ask for not something the compiler writer thinks is suitable punishment.

It's only undefined behavior (on C) because the (C) standard body decided to specify it that way.

There's no reason to specify things as UB as it's currently understood.

-ftrapv is an implementation-provided flag that defines the behavior of some operations that are otherwise not defined by the language standard. The implementation could define the behavior (under the same or different flags) to this newly introduced trap representation as well (no need to actually trap).

Having said that this should be a new type, adding more UB to existing types is a bad idea.

you trade -fwrap for -ftrap, which is IMHO better. You would need hardware support for it to be even half efficient though.

I don't hate the idea, but doing it for existing int types might be a non-starter due to backward compatibility.

Reply on news.ycombinator.com