3 ms·
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 would
by torstenvl 3y ago
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.
- atq2119 3y agoI think the idea is that overflowing would be a guaranteed trap of some kind, i.e. defined behavior.
- eru 3y agoYou don't have to introduce more undefined behaviour. A trap could be very defined behaviour.
- torstenvl 3y agoNo. 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 undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined."
- akoboldfrying 3y agoI 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.
- torstenvl 3y agoIt 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.
- atq2119 3y agoI 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.
- Gibbon1 3y agoA trap is something the programmer should have to ask for not something the compiler writer thinks is suitable punishment.
- deleted 3y ago[deleted]
- marcosdumay 3y agoIt'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.
- gpderetta 3y agoyou 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.
- saagarjha 3y ago-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.
- planede 3y ago-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.