[bombcar]

It is possible - but not whilst maintaining standards-compliance and there are always/often another one where you least expect it.

At the root is taking a “assume the programmers know what they are doing” language and turning it into a “assume the programmers are drooling morons” language.

[not2b]

I think it's the opposite: compiler writers under pressure to produce fast code assume that the programmers are smart, not morons, and that they understand the rather complex rules.

For example: the compiler is assuming someone isn't ignorant and knows, for example, if they want to write a variable as one type and read it as another, they need to consider two things: they are now in implementation-dependent territory (big endian vs little endian effects, for example), and they need to use unions, not just casts, if the same data can be interpreted as two different types and neither is array of char. Failure to use unions properly triggers aliasing problems.

[ncmncm]

Amusingly, unions are also defined so that operations that pun types are undefined. Gcc has private extensions that provide a way to pun types in unions, but those are not portable.

Specifically: if you have a union with members a and b, and you assign into member a, then reading from member b afterward is, by the C and C++ Standards, usually undefined. You are presumed to have some way to know that member a is live, and use that. You can then write into b, and later read that back out.

[not2b]

The C99 and C11 standards say that the behavior is unspecified (in standard-ese, "unspecified" and "undefined" are different), meaning that the standard doesn't say what you get. Of course that's true: the result is different on a big-endian and a little-endian machine. Packing the bytes of a double might generate a signalling NaN so you get a trap when you read it, or not, and the standards don't require that floating point representations match the IEEE standard, either.

[tpush]

That’s undefined only in C++ but not in C, AFAIK.