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