As I understand it, the C spec defines what are valid programs, and for valid programs, either specifies what their observable side effects must be, or leaves them either unspecified or implementation defined. Importantly, programs with undefined behaviour are excluded from the class of valid programs; thus the spec imposes no requirement on the resulting behaviour. To quote,
> Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to […]
And I think this is where “can’t happen” comes in: in the case of undefined behaviour, the compiler is free to emit whatever it pleases, including pretending it cannot happen!
"Can't happen" comes from the fact that the compiler optimizes for defined behaviour, not undefined behaviour. Making defined behaviour fast at the expense of undefined behaviour looks the same as assuming undefined behaviour can't happen in a number of cases. Eg. if you dereference a pointer then check it for null, naturally the compiler will remove the later check. We can describe that as the compiler making the defined case fast, or we could describe it as the compiler assuming the pointer "can't" be null. The latter description is easy to think about, and generalizes broadly enough, to be a common way of describing it.
> Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to […]
And I think this is where “can’t happen” comes in: in the case of undefined behaviour, the compiler is free to emit whatever it pleases, including pretending it cannot happen!