KSat/fsfw
18
6
Fork 0
forked from fsfw/fsfw
Code Issues Pull Requests 1 Releases Wiki Activity

Compile time const event definitions and compile error for unique IDs above limit #53

Merged
muellerr merged 2 commits from baumgartl/events into main 2025-03-18 14:39:35 +01:00
Conversation 2 Commits 2 Files Changed 5 +14 -13
tbaumgartl commented 2025-03-14 13:42:39 +01:00
Member
Copy Link

See attached, a nice screenshot of what can happen if you don't limit the unique id to 100 entries (PCDU ID = 193 ; Syrlinks ID = 194. Given that i started the syrlinks unique IDs at 2).

I.e: given any two adjacent subsystem IDs, if the lower one chooses to select a unique ID above 99, it may (based on the selected severity) bleed into the next subsystem IDs namespace.

To at least warn the user of this happening, i've templated the makeEvent function to be truly compile time const, to then be able to static_assert the unique ID.

Please Note, that the generators must also be updated for the export to function properly. See this PR fsfw/fsfwgen#4 for the required adjustment.
I've kept the generator changes minimal and backwards compatible.

This fix as well as backwards compatibility has been tested on

https://git.ksat-stuttgart.de/source/source-obdh_obsw/sourceobsw/-/merge_requests/220

and

https://git.ksat-stuttgart.de/source/source-obdh_obsw/sourceobsw/-/merge_requests/181

See attached, a nice screenshot of what can happen if you don't limit the unique id to 100 entries (`PCDU ID = 193 ; Syrlinks ID = 194`. Given that i started the syrlinks unique IDs at 2). I.e: given any two adjacent subsystem IDs, if the lower one chooses to select a unique ID above 99, it may (based on the selected severity) bleed into the next subsystem IDs namespace. To at least warn the user of this happening, i've templated the `makeEvent` function to be truly compile time const, to then be able to `static_assert` the unique ID. Please Note, that the generators must also be updated for the export to function properly. See this PR https://egit.irs.uni-stuttgart.de/fsfw/fsfwgen/pulls/4 for the required adjustment. I've kept the generator changes minimal and backwards compatible. This *fix* as well as backwards compatibility has been tested on https://git.ksat-stuttgart.de/source/source-obdh_obsw/sourceobsw/-/merge_requests/220 and https://git.ksat-stuttgart.de/source/source-obdh_obsw/sourceobsw/-/merge_requests/181
image.png
30 KiB
image.png
tbaumgartl self-assigned this 2025-03-14 13:42:39 +01:00
tbaumgartl added 2 commits 2025-03-14 13:42:39 +01:00
tbaumgartl requested review from muellerr 2025-03-14 13:42:39 +01:00
muellerr approved these changes 2025-03-18 14:32:33 +01:00
Dismissed
muellerr approved these changes 2025-03-18 14:39:20 +01:00
muellerr merged commit 55b8d01b93 into main 2025-03-18 14:39:35 +01:00
muellerr deleted branch baumgartl/events 2025-03-18 14:39:36 +01:00
Sign in to join this conversation.
Reviewers
No Reviewers
muellerr
Labels
Clear labels
bug
Something is not working
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
question
More information is needed
wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Assignees
Clear assignees
ahinkel dwoodward fbalassa gaisser jgerhards lrajer mdemke meierj mluz mohr msenger mspahr mtompert muellerr nehlichp phoffmann PScheurenbrand taheran tbaumgartl
No Assignees tbaumgartl
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: KSat/fsfw#53
No description provided.
Delete Branch "baumgartl/events"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?