It's not a particular operation that is the problem, it's writing a whole real-life program with no UB that is the problem.
Even so, one example in C++ where it's almost impossible to avoid UB is treating a piece of memory as both a struct and raw bytes with guarantees of no copying. This comes up a lot in network packet processing.
Well, in practice memcpy and std::bit_cast will not normally copy, if you're careful with how you use the variables and so on, so it's not completely impossible to do this.
There are also compilers (g++ for example, if I understand correctly) that define type punning through unions to work like in C (allowing you to read and write through different members of the union, which the C++ standard prohibits).
I bet they use UB in more than one place. It's just some instance of UB that compilers aren't exploiting with crazy interpretations that lead to faster non-working programs.
The people saying that it's technically possible to create that code without UB say that with a certainty that isn't viable. You don't need to just read the standard from beginning to end to determine if your code has UB, you need to also remember it all. Some part of it not applying to your case doesn't stop the UB on that part from appearing in your code, and there isn't a usable list of UB you can quickly check against (the closest that exists is the set of UB that compilers are using on their crazy extrapolations, what is not the same thing).
There is just no way to know that you avoided it all.
Not offhand, no. It's been more than 5 years since I last did any serious C dev work.
But for an entertaining read, there are some fun stories floating around about Linux vs GCC with the kernel devs resisting compiler optimisations, and even holding back the "supported compiler versions" over it :)
