This post has no point.
Developers must avoid UB in their code, at all costs. Wondering what a specific compiler will do with your UB code is useless: as soon as you realise you have UB, go and fix it!
Developers must avoid UB in their code, at all costs. Wondering what a specific compiler will do with your UB code is useless: as soon as you realise you have UB, go and fix it!
The resulting "reasoning" can be counter-intuitive, and seeing what happens and what problems it can introduce must be instructive to people who are not aware.
Better informed/educated C programmers is an improvement on the state of the world, in my opinion.
UB is a post-facto justification for compiler optimizations that only work on non-buggy programs. It's a circus because programs have bugs.
Given that reality, knowing what your compiler will do with UB is useful and important because you're going to see it all the time in debugging. Even if it's ugly, it needs to be treated as a familiar face.
The more you refuse to accept undefined behaviour, the more it will hurt when it will bite you!
Stop turning around the problem and fix your code.
Given that, plus the reality that we insist on continuing to write a million lines of C++, treating UB as something you'll see frequently in your career is probably the reality-based behavior.
Sure it is! I'm not talking about skills: everybody writes UB, at any time. I'm talking about attitude: when you see UB, you must strive to remove it, not to protect it!
I didn't recognize it as your position because you presented "Developers must avoid UB in their code, at all costs" as supporting the preceding statement "This post has no point;" if your point is "developers should remove UB when they see it," then the point of this post is helping people see what UB looks like at the next layer of abstraction down as an aid to identifying and removing it.
(The C++ standard is over 2,000 pages. It's impractical to believe developers see UB by reading the C++ source code; most is identified by an application behaving incorrectly followed by inspection of the machine code to understand where the developer's assumptions about the C++ specification failed to match with the actual specification).
Maybe I did not choose my words properly, I apologise.
If a compiler is certain there's UB should it format the developer's hard drive immediately, or does it have to wait until the program is run before formatting to be standards compliant?
On a more serious level, should it emit a warning? If it knows UB is reached, a warning sounds reasonable, but it's pretty rare that a compiler is 100% certain something is reached, and that analysis is probably not worth the cost.
The standard has enough variants of UB that both options are possible!
For normal runtime UB (e.g. division by zero), it needs to wait until it is certain that the undefined code will actually be executed. So compilation/linking must not fail, the behavior is only undefined if the program is actually run.
IFNDR (ill-formed, no diagnostic required) is a different kind of UB; here it is expected that compilation/linking may already fail.
Then there's also the infamous "preprocessor UB" (e.g. https://wg21.link/p2621), which reuses the "undefined behavior" terminology despite not having anything to do with runtime semantics. I guess this is where the compiler might format your hard drive (old gcc versions actually launched nethack on undefined pragmas!).
You seem to care about developers avoiding UB. Exploring how compilers warn or don't warn for some of these cases is very meaningful - maybe it can lead to new warnings, or better tools so that developers can avoid UB.