Ah, nice. Hadn't seen those yet. Oh well, I notice that the decode_big_endian() is more elegant to use than osmo_load64be_ext(), since passing a length of less than 8 bytes to decode_big_endian() writes the N least significant bytes, and allows this: uint16_t val; val = decode_big_endian(buf, sizeof(val)); It has the desired result. However this: uint16_t val; val = osmo_load64be_ext(buf, sizeof(val)); will write the bytes bound to the "wrong", most significant end of the uint64_t, and only zero is written to val. So I would need to explicitly use osmo_load16be(). Which is less elegant, isn't it? Is it about performance? Would changing that behavior break anything besides bitrev_test.c? (It checks for exactly this ordering) I'd like to change only the osmo_loadXXbe_ext() function, so that it writes the least significant bytes, like decode_big_endian() does. But first, does it write the most significant end for a reason? If it doesn't, we don't actually need to generate functions for each integer size. Instead we can glorify the decode_big_endian() and encode_big_endian(), made threadsafe, to become osmo_load/store*(). Right?? Except for bitrev_test.c, all callers I found (in my currently cloned few source trees) use only the non-"_ext" functions, and would not be affected by the change at all. ~Neels P.S.: Holger, after I said to you that osmo_loadXXbe_ext is not less elegant after all, I re-re-realized that it is indeed still less elegant...