Re: CVS commit: src/sys/arch/atari/stand/installboot

[Taylor R Campbell <campbell+netbsd-source-changes-d%mumble.net@localhost>]

   Date: Sun, 16 Nov 2014 12:51:34 +0900
   From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>

   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.