Details
Description
Compilers are getting (too) smart, and they can generate incorrect code, for unaligned access, since it is "undefined behavior".
Also, avoid macros, like MySQL did, it is almost impossible to read now. `static inline` is good enough, and documents correct datatype
of the return value.
- the correct optimization for all little endian is something like this.
static inline uint uint4korr(const void *p) |
{
|
uint ret;
|
memcpy(&ret, p, 4); |
return ret; |
}
|
It is optimized by the compiler to a single instruction, if alignment is unimportant in that architecture.
Corollary : There is no whatever reason to have special code for Intel, memcpy is the best.
We only need set of such static inline functions for big and little endian architectures, nothing more.
For big-endian, byte-wise reading and calculating are in order. That code might also by optimized by the compiler, if architecture has a byteswapping instructions.
Attachments
Issue Links
- blocks
-
MDEV-39027 suboptimal code for InnoDB big endian access functions (MSVC, GCC)
-
- Closed
-
-
MDEV-39150 Some data conversion macros fail to use memcpy()
-
- Open
-
- relates to
-
MDEV-20277 Disable -fno-strict-aliasing
-
- Open
-
-
MDEV-37148 Unaligned access in strings/ctype.c, crashes with upcoming GCC 16 (or UBSAN)
-
- Closed
-
-
MDEV-37786 my_convert randomly crashes when converting from utf8mb3 to utf8mb4
-
- Closed
-
-
MDEV-38989 main.ctype_utf16le SEGV in Ubuntu 26.04 (amd64v3)
-
- Closed
-
-
MDEV-37717 UBSAN: runtime error: store to misaligned address for type 'uint32' (aka 'unsigned int'), which requires 4 byte alignment in extra/comp_err
-
- Closed
-
-
MDEV-38398 SEGV on amd64v3 instruction set in my_convert
-
- Closed
-