memcpy() inlining and alignment

[Mike Stump]

> From: Jason Thorpe <thorpej@netbsd.org>
> Date: Fri, 03 Mar 2000 17:47:09 -0800

> The difference is in the intent of the code!  I, as a programmer,
> made a call to memcpy(), which takes a "void *" argument, and is
> defined by the C standard to operate on bytes.  I did not
> dereference a pointer to a data type with certain known alignment
> constraints.

> Obviously a memcpy() implementation can make optimizations, but those
> optimizations should not have side-effects.

> I consider an unaligned access (which may be fatal or produce incorrect
> data) to be a side-effect (and I'm sure I'm not alone here :-)

> Now, if memcpy() were defined to take "unsigned int *" arguments, I
> would agree with you that the compiler would be justified in making
> alignment assumptions.  However, it doesn't, so I think that the
> compiler's assumption of alignment is incorrect here.

There doesn't exist a case of code that doesn't feature undefined
behavior in C, where you can arrange to make memcpy in gcc fault.  In
other words, since you can't (within the scope of the standard) see
the side-effect, the compiler is allowed to generate code that does
have side-effects, it is only as if it didn't have side-effects.  To
see the side effect, you must first have undefined behavior, that is a
necessary precondition.