On 01/29/2013 01:13 PM, John Ferlan wrote:
>> Mathematically what you propose with the memcpy() works;
however, I come
>> from an architecture where a memcpy to an unaligned address causes a
>> fault
>
> Such a memcpy() implementation would be flawed, and should be reported
> as a bug to that vendor; thankfully, these days, most libc do not have
> that flaw. The C standard guarantees that memcpy() is required to work
> on unaligned copies (for a certain definition of work; you may still end
> up splicing together unrelated portions of adjacent integers when
> reading things back as integers, but byte-for-byte, the operation is
> well-defined).
>
Alpha and Itanium have some (silent unless noise enabled) heartache when
the "to" address is "0x7ffe8f2b8cf1" (or x2, x3, x5, x6, x7, etc).
Ending with x0 & x8 are preferred while x4 & xc tolerated. If the noise
isn't turned on, the application performs poorly due to excessive
alignment faults.
No one's arguing that alignment doesn't matter - it is very much in the
compiler's favor to align things, because performance is noticeable on
unaligned copies. But the point remains that memcpy() is required to
work on unaligned memory, even if the compiler does a good job at
normally aligning things so that most uses of memcpy don't have to
suffer speed penalties.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org