4 ms·
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
by torstenvl 3y ago
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 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.