5 ms·

Why not just use memcpy()?

• greesil 3y ago
  Arrays?
• j16sdiz 3y ago
  Because, in some hardware, unaligned read is ok. and you want to take advantage of the hardware feature?
  • dzaima 3y ago
    Both gcc and clang will optimize a memcpy to an unaligned load/store where possible.
    • j16sdiz 3y ago
      If the compiler is so smart, I guess it could insert a memcpy when needed? The standard, you may say.. I would argue it's the standard need to be changed. The modern reading of the standard is not useful as a low-level language and is unsafe as a high-level language.
      • dzaima 3y ago
        Right, I agree that it would be nice to have some way to request unaligned load/store to be permitted, alike -fwrapv for signed int wrapping. But nevertheless the UB behavior is a reasonable option that's beneficial for other things.
      • rsaxvc 3y ago
        > If the compiler is so smart, I guess it could insert a memcpy when needed? If I'm reading your comment and the blog post correctly, the compiler would need a memory like access on every multibyte pointer argument where the compiler cannot otherwise prove alignment. Is that correct?
        • rsaxvc 3y ago
          > memory like I meant memcpy()-like
        • dzaima 3y ago
          Internally, the compiler could represent it however it wants. LLVM IR's load/store instructions just have an "align" property, which is usually sizeof(the type), but can be set to 1 to mimic memcpy (and indeed llvm/clang immediately translate a memcpy to such - https://godbolt.org/z/7T46a6aqT https://godbolt.org/z/7T46a6aqT). Though it seems that, independent of this, it assumes that an int* in general will be 4-byte-aligned, so e.g. https://godbolt.org/z/aWTEd4s3K https://godbolt.org/z/aWTEd4s3K still has an "align 4" despite using memcpy. So one must also cast to a char* before using memcpy() to actually have it work. yay for more footguns!
• IshKebab 3y ago
  That is the solution they recommend.