Re: memcpy() inlining and alignment

[Jason Thorpe <thorpej at netbsd dot org>]

On Fri, 3 Mar 2000 17:28:31 -0800 
 "David S. Miller" <davem@redhat.com> wrote:

 > libc does not have available the type and alignment information
 > that the compiler does.
 > 
 > For example:
 > 
 > struct foo {
 >        unsigned int x;
 > };
 > 
 > int read_foo(struct foo *p)
 > {
 > 	p->x;
 > }
 > 
 > Can the compiler assume that loading the p->x value via a
 > 32-bit word load instruction is safe?  If so, why can it not
 > make the same assumption when inlining a call to memcpy.
 > How do the alignment rules for such a structure change in
 > the two cases?

There *is* a difference, here...

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.

	-- Jason R. Thorpe <thorpej@netbsd.org>