On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote: > On Sat, 24 Nov 2007 15:50:52 +0000 > Luciano Rocha <[EMAIL PROTECTED]> wrote: > > > > > Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems > > in any case. Intelligent ones, like the one provided in glibc, first copy > > bytes till output is aligned (C file) *or* size is a multiple (i686 asm > > file) > > of word size, and then it copies word-by-word. > > > > Linux's x86_64 memcpy does the opposite, copies 64bit words, and then > > copies the last bytes. > > > > So, in effect, as long as no packed structures are used, memcpy should > > be safer on *int, etc., than *char, as the compiler ensures > > word-alignment. > > > > It most certainly does not. gcc will assume that an int* has int alignment. > memcpy() is a builtin, which gcc can translate to pretty much anything. And C > specifies that a pointer to foo, will point to a real object of type foo, so > gcc can't be blamed for the unsafe typecasts. I have tested this the hard > way, so this is not just speculation.
Yes, on *int and other assumed aligned pointers, gcc uses its internal version. However, my point is that those pointers, unless speaking of packed structures, can safely be assumed aligned, while char*/void* can't. > In other words, memcpy() does _not_ save you from alignment issues. If you > cast from char* or void* to something else, you better be damn sure the > alignment is correct because gcc will assume it is. Nothing does, even memcpy doesn't check alignment of the source, or alignment at all in some assembly implementations (only word-copy, without checking if at word-boundary). -- lfr 0/0
pgpSqyJvQFOo9.pgp
Description: PGP signature