> Second, it is an error to call gcc's behavior "defined in documentation" as if that means it's okay to use. It's just a flag to support obsolete code. Long-te

> Second, it is an error to call gcc's behavior "defined in documentation" as if that means it's okay to use. It's just a flag to support obsolete code. Long-term, the assumption that gcc will retain flags to support antique code is optimistic. Type punning through a union works on GCC without -fno-strict-aliasing, and is documented in multiple places. Among others, it's suggested as an alternative to fix code broken under strict aliasing here: https://gcc.gnu.org/bugs/#nonbugs https://gcc.gnu.org/bugs/#nonbugs. It's also relatively safe to assume that GCC will continue to be able to compile the Linux kernel for the indefinite future, since it would be very high profile, cause a ton of drama, and result in many people to moving away from GCC (including contributors). It seems very unlikely to be a smart decision. (That's not to say lower profile projects than the linux kernel should rely on this. Using memcpy/memmove is just as fast and that much more difficult).