[3.2] avoid redefining _mm_crc32_u64 which can lead to compile errors #242
Conversation
| #else | ||
| uint64_t _mm_crc32_u64(uint64_t a, uint64_t b ); | ||
| uint64_t mm_crc32_u64(uint64_t a, uint64_t b ); | ||
| #define MM_CRC32_U64I mm_crc32_u64 |
There was a problem hiding this comment.
Should we use FC_MM_CRC32_U64I instead?
There was a problem hiding this comment.
I was trying to keep the same length to avoid touching a bunch of whitespace over in CHUNK() 😅
Since this define is local to a .cpp it doesn't seem like there is much risk of a clash? Possibly mm_crc32_u64() should be moved in to fc's namespace though?
There was a problem hiding this comment.
actually if _mm_crc32_u64 is just placed in to a namespace I think that's safe. maybe that's the better choice 🤔
There was a problem hiding this comment.
I didn't notice this was only in this one source file. I think it is fine as is.
| #else | ||
| uint64_t _mm_crc32_u64(uint64_t a, uint64_t b ); | ||
| uint64_t mm_crc32_u64(uint64_t a, uint64_t b ); | ||
| #define MM_CRC32_U64I mm_crc32_u64 |
There was a problem hiding this comment.
I didn't notice this was only in this one source file. I think it is fine as is.
Defining our own
_mm_crc32_u64implementation can clash with some compilers. Not too surprising since that's a reserved name in global scope. In particular, AppleClang will give an error:Rename our impl to just
mm_crc32_u64and redirect to eithermm_crc32_u64or_mm_crc32_u64via a new macro.