[virexene]

your compiler might choose to make that the "implementation-defined behavior", but another compiler could choose to always ignore it and give you no easy means of diagnosis.

my understanding is that the proposal of "erroneous behavior" limits the scope of the consequences of triggering the behavior (like implementation-defined behavior), while still clearly marking it as erroneous and something to be diagnosed (like undefined behavior).

[Voultapher]

I think I understand the motivation, but I'm not sure it is thought through. Taking the signed integer example, would platform defined wrapping be suitable behavior in the setting of erroneously defined behavior? If not, that would make it a poor fit for integer overflow, adding a branch to most signed integer math ops in release builds is a non starter for C++ projects.

Regarding the diverse compiler point you made, that argument can be used to torpedo most ideas in this space. For example sanitizers started in clang, and now gcc and msvc have similar options, if something is a good idea, chances are the others will copy it. And relying on erroneously defined behavior (EB) to be a hard error, means relying on behavior that can differ across implementations and platforms which is problematic in itself. Plus, even relying on a hard error implies that EB has to be an error which is problematic for the reasons outlined above, or means it can't be used in the places you'd like to use it like signed integer overflow.