> > Calls to rte_memcpy_generic could result in unaligned loads/stores for > > 1 < n < 16. This is undefined behavior according to the C standard, > > and it gets flagged by the clang undefined behavior sanitizer. > > > > rte_memcpy_generic is called with unaligned src and dst addresses. > > When 1 < n < 16, the code would cast both src and dst to a qword, > > dword or word pointer, without verifying the alignment of src/dst. The > > code was changed to use a packed structure to perform the unaligned > > load/store operations. This results in unaligned load/store operations > > to be C standards-compliant. > > Still not sure we need to fix that: > This is x86 specific code-path, and as I remember on x86 there are no > penalties for unaligned access to 2/4/8 byte values. > Though I like introduction of rte_mov15_or_less() function -t helps > with code dedup.
Thanks for your input Konstantin. Much appreciated. Just to make sure I understand, can you please confirm that we do not want to fix the fact that unaligned access in C is undefined behaviour? I understand that X86 allows unaligned accesses but since this isn't assembly code, we have to go by what the C standard allows. Also, do you have any opinion on the strict aliasing violation (as was pointed out by Georg)? I suggested adding __may_alias__ thinking it would likely fix the issue, but I'd really like to get confirmation from someone who has better knowledge of how the attribute works exactly. Thanks
