Bug #6043
closedNo 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)
Related issues
Updated by neels about 1 year 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.
Updated by jolly about 1 year ago
I would split up gsm414_gprs_test_mode_cmd.d into d_lo and d_hi, because we cannot change how the compiler arranges elements that extends over byte boundary.
Updated by laforge about 1 year ago
note that the python script should also fail if there's anything in a struct definition
it doesn't support. Otherwise we end up with hidden bugs like this one...
Updated by neels about 1 year ago
I thought it does complain about anything that is not 8 bits... apparently there's still a blind spot.