This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.debump ... any opinions on changing osmo_load*_ext() so that it always writes the least significant end instead of (currently) the most significant one? Details below... It would technically require a major version bump, but are there likely any callers relying on current behavior? It would not make much sense anyway (maybe a partial read, but I see no way to resume such read). Thanks, ~Neels On Fri, Oct 09, 2015 at 01:44:54AM +0200, Neels Hofmeyr wrote: > > > +uint64_t decode_big_endian(const uint8_t *data, size_t data_len) > > > +uint8_t *encode_big_endian(uint64_t value, size_t data_len) > > have you looked at osmo_load64le_ext of libosmocore? I think you don't need > > these routines. and it applies to GSUP too. > > 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... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151019/59f8e090/attachment.bin>