osmo_loadXXbe_ext -- was: [PATCH 1/8] libcommon: soak up three static functions.

[Neels Hofmeyr]

> > +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/20151009/0267e3eb/attachment.bin>