Bug #6043
openNo endianness conversion of uint16_t or larger integers
0%
Description
contrib/struct_endianness.py automatically converts endianness of uint8_t, but not larger integers.
This means that in file "include/osmocom/gsm/protocol/gsm_04_14.h" the structure "gsm414_gprs_test_mode_cmd" is not converted correctly to big endian. (uint16_t remains unchanged)
Updated by neels 6 days ago
This script indeed acts only on uint8_t, and I thought we only have uint8_t
sub-byte length integers in our headers.
I'm not entirely sure how a uin16_t affects this. In other places, if members
span more than one byte, we use 'lo' and 'hi' components. Look for example at
struct gsm48_range_512 in libosmocore/include/osmocom/gsm/protocol/gsm_04_08.h
So ways to fix:
- split up gsm414_gprs_test_mode_cmd.d into d_lo and d_hi
OR
- make the struct_endianness.py generate correct output for uint16_t with sub-byte length.
- For this we first need to test and confirm how uint16_t are handled on little vs big endian.
BTW, I'm also not entirely sure for what or who we even support big endian in
the first place.
And I wish the C compiler would make this script completely obsolete, because
it is in fact brain damaged to expect all code everywhere to have special shims
for little vs big endian.