Project

General

Profile

Actions

Bug #6043

closed

No endianness conversion of uint16_t or larger integers

Added by jolly 9 months ago. Updated 4 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
libosmocore
Target version:
-
Start date:
05/24/2023
Due date:
% Done:

0%

Spec Reference:

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

Related to Cellular Network Infrastructure - Bug #6122: remove big endian supportNewosmith07/31/2023

Actions
Actions #1

Updated by neels 9 months 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.

Actions #2

Updated by jolly 9 months 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.

Actions #3

Updated by laforge 9 months 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...

Actions #4

Updated by neels 9 months ago

I thought it does complain about anything that is not 8 bits... apparently there's still a blind spot.

Actions #5

Updated by laforge 4 months ago

  • Related to Bug #6122: remove big endian support added
Actions #6

Updated by laforge 4 months ago

  • Status changed from New to Rejected

we decided to drop big endian support, see #6122. rejecting this issue.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)