correct. In my experience a focus on UB (often actually said U.B.) tends to come from the C++ community, although a lot of it trickles down to the C community as well. I can recommend watching a few talks from C++ conferences. I especially enjoyed ones by Matt Godbolt, and Miro Knejp.
Not correct. Most UB is the same in C and C++. If you disallowed optimizations based on UB, it might have more effect on C++ programs, just because C++ tends to more deeply inlined abstractions that can benefit more from them. But those don't tend to need much attention. The cases people worry about are more common in C code, just because the concept of type is less important in C.
Or are you saying that UB is not from the C++ community? That could certainly be true, I am just describing the situation as I see it where C++ disallows more types of casting or reinterpreting than C does (even if compilers allow it).
One salient example I heard was that the only way to legally read the bits of a float in C++ is to memcpy the float onto an integer type. whereas in C its legal (I believe by using a union).
Nope! Same. BTW the memcpy is always optimized out, so you might as well; then it's totes portable, C or C++. You can always build up an object (int, float, struct) from char values. Technically they are supposed to have come from another value of the same type, but the compiler can't really tell where the bytes came from, so has to assume they must have come from there.
C does have a thing where a void pointer can be copied into any other pointer, without a cast, and operations with the typed pointer are OK. Technically, the pointer value is supposed to have been copied to the void pointer from the same type, but realloc has to work. Note, realloc does give you alignment guarantees you don't get from pointers to random things.
Nothing else is portable. Unions, other pointer casting, all is UB unless your compiler extends the definition. So, Gcc has an extension to make unions, used in a certain way, well-defined. Probably Clang copies that. You would have to look up exactly what. But the memcpy hack works in all compilers. You won't use it often enough for the extra verbosity to be a problem.
In C you're free to get the address of the float (presuming it's not in a register) and cast that address to a pointer to an array of char, which doesn't copy anything, just re-decrees, from that point on, to the code generator of the compiler what assembly code is generated.
Right, I should not have said you have to memcpy. You can poke bytes any way you like, in any order you like. But! memcpy is known to compiler optimizers, so is more reliably optimized away.
