Date: Sun, 16 Nov 2014 12:51:34 +0900 From: Izumi Tsutsui <tsut...@ceres.dti.ne.jp>
My understanding is the strict aliasing rule is referred by compiler for reorder optimization etc. If the access via union is still invalid, why does the strict gcc48 no longer complain against it? It's access via two different pointers, which happen to have the same bits by virtue of being stored in a union -- the union doesn't actually do anything about aliasing of the pointed-to object, except probably confuse gcc. The point is that you can't get at one object in memory through two pointers of different types (except to get at a non-char object via a char pointer). The compiler sometimes tries to detect when you're violating this rule, but it can't always -- casting through void *, or passing the pointer through a union of pointer types, may suppress warnings, but will still violate the rule. It's TierII MD code, so maintainability is much more important than perfection (unless you will take maintainership of this installboot). I read the thread, but I'm not clear on how using memcpy in order to avoid undefined behaviour reduces maintainability. > I don't see any byte ordering issues here that weren't present before. Currently it may work. But once we will try to make the MD installboot merged into MI usr.sbin/installboot, accessing variables via different types always confuse programmers who don't know actuall intention (which is the host endian value, which is the target endian value etc). Changing `*(uint16_t *)p = v' to `memcpy(p, &v, 2)' doesn't change any of that. Seems to me if one wants to clarify the intention, one should add host16enc and target16enc and replace memcpy by whichever of those is appropriate.
