Cmon, this is not about naming, this is about non-generic code in generic header.
IMO hiding such a little operation behind a macro/function just hurt readability. Furthermore, considering that this function is only used once in the provided patch and that word ordering on RISC-V is not about to change anytime soon, it is perfectly fine to inline the code.
Making a u32 pointer from to u16’s isn’t a generic operation because it has to make assumptions about how the pointers work (in particular what endianess they have)
Cmon, this is not about naming, this is about non-generic code in generic header.
IMO hiding such a little operation behind a macro/function just hurt readability. Furthermore, considering that this function is only used once in the provided patch and that word ordering on RISC-V is not about to change anytime soon, it is perfectly fine to inline the code.
(a << 16) | bis about the most generic code you can get. How is that remotely RISC-V specific?Making a u32 pointer from to u16’s isn’t a generic operation because it has to make assumptions about how the pointers work (in particular what endianess they have)
What makes you think it’s making a pointer? Nobody said anything about that.
Oh my bad I don’t know where I got that from lol
Nw. You’re also wrong about endianness. This function would be written exactly the same irrespective of endianness:
uint32_t u16_high_low_to_u32(uint16_t high, uint16_t low) { return (high << 16) | low; }That is endian agnostic.