Let's say I go to compile some poorly-written C++ source code that invokes undefined behavior, and therefore (as they say) "anything can happen".
From the perspective of what the C++ language specification deems acceptable in a "conformant" compiler, does "anything" in this scenario include the compiler crashing (or stealing my passwords, or otherwise misbehaving or erroring-out at compile-time), or is scope of the undefined-behavior limited specifically to what can happen when the resulting executable runs?
The normative definition of undefined behavior is as follows:
behavior for which this International Standard imposes no requirements
[ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. Evaluation of a constant expression never exhibits behavior explicitly specified as undefined. — end note ]
While the note itself is not normative, it does describe a range of behaviors implementations are known to exhibit. So crashing the compiler (which is translation terminating abruptly), is legitimate according to that note. But really, as the normative text says, the standard doesn't place any bounds for either execution or translation. If an implementation steals your passwords, it's not a violation of any contract laid forth in the standard.