I am not a C developer, but I found the “helper has a terrible name” and “it’s not clear what the helper is doing” arguments a bit weak.
Who in they right mind does not think the helper creates a 32 bytes word by putting the 16 bytes of the first argument followed by the 16 bytes of the second one ?
It’s bits, not bytes. And endianness is a huge consideration in systems programming. And it’s basically Linus’ whole role at this point to enforce extreme consistency and standards since the project is so large with so many contributors
Yeah it actually is fairly common to have the high word first because humans unfortunately picked the wrong endianness, and integers are written in big endian.
E.g. what value would you expect from u16x2_to_u32(0x1122, 0x3344)? If you said 0x11223344…
Still, the rant is stupid because all that needs to happen is to fix the name.
Honestly it’s really surprising that the kernel doesn’t already have a library of reliably but manipulation functions for common stuff like this.
I am not a C developer, but I found the “helper has a terrible name” and “it’s not clear what the helper is doing” arguments a bit weak.
Who in they right mind does not think the helper creates a 32 bytes word by putting the 16 bytes of the first argument followed by the 16 bytes of the second one ?
It’s bits, not bytes. And endianness is a huge consideration in systems programming. And it’s basically Linus’ whole role at this point to enforce extreme consistency and standards since the project is so large with so many contributors
Yeah it actually is fairly common to have the high word first because humans unfortunately picked the wrong endianness, and integers are written in big endian.
E.g. what value would you expect from
u16x2_to_u32(0x1122, 0x3344)? If you said 0x11223344…Still, the rant is stupid because all that needs to happen is to fix the name.
Honestly it’s really surprising that the kernel doesn’t already have a library of reliably but manipulation functions for common stuff like this.