You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The ES perf code uses macros to determine the array length based on the overall array size (via sizeof()). Problem is, these calculations hard-code a uint32 type as the divisor (element size) which may not always be true.
To Reproduce
Change the definition of the masks in TLM to be e.g. uint8-based instead of uint32-based. Array lengths are now calculated incorrectly, because it divides by sizeof(uint32) which would now be wrong.
Expected behavior
Should use [0] to get the actual type of the element, this makes the calculation future-proof, as it does not assume/repeat the array element type (adheres to DRY principle)
Cleans up the array length calculation for perf structs to not assume
a specific base element type (uint32). This also makes the definitions
much more readable.
Describe the bug
The ES perf code uses macros to determine the array length based on the overall array size (via
sizeof()
). Problem is, these calculations hard-code auint32
type as the divisor (element size) which may not always be true.To Reproduce
Change the definition of the masks in TLM to be e.g. uint8-based instead of uint32-based. Array lengths are now calculated incorrectly, because it divides by
sizeof(uint32)
which would now be wrong.Expected behavior
Should use
[0]
to get the actual type of the element, this makes the calculation future-proof, as it does not assume/repeat the array element type (adheres to DRY principle)Code snips
cFE/modules/es/fsw/src/cfe_es_task.c
Lines 51 to 57 in c161cf0
System observed on:
Ubuntu 21.10
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: