QueueMapManager bugfix #444

muellerr · 2021-07-14T10:31:10+02:00

muellerr commented

2021-07-14 10:31:10 +02:00

This bug slipped the SOURCE tests and the internal unit tests. But surfaced on the STM32 FSFW example. The post-increment operator was used by accident instead of the pre-increment operator which caused the first MessageQueue ID assigned by the QueueMapManager to be 0. This is the current value for NO_QUEUE.

I suspect that the first queue created that way was not used during the SOURCE tests or in the internal unit tests in a way that would have caught this bug.

Solution is to start at 1 now, clarify via comment, and continue using the post-increment operator.

Furthermore, the NO_QUEUE value is skipped now

This bug slipped the SOURCE tests and the internal unit tests. But surfaced on the STM32 FSFW example. The post-increment operator was used by accident instead of the pre-increment operator which caused the first MessageQueue ID assigned by the QueueMapManager to be 0. This is the current value for `NO_QUEUE`. I suspect that the first queue created that way was not used during the SOURCE tests or in the internal unit tests in a way that would have caught this bug. Solution is to start at 1 now, clarify via comment, and continue using the post-increment operator. Furthermore, the NO_QUEUE value is skipped now

muellerr added the

bug

label 2021-07-14 10:31:10 +02:00

muellerr added 1 commit 2021-07-14 10:31:11 +02:00

clarification 8f1a54aa19

muellerr added 1 commit 2021-07-14 10:34:09 +02:00

additional safety by check against NO_QUEUE f6d1b8981c

muellerr added 1 commit 2021-07-14 10:34:47 +02:00

using current ID 5f0a3f3baa

muellerr added 1 commit 2021-07-14 10:35:47 +02:00

this is the correct implementation df1d5e5005

muellerr added a new dependency 2021-07-14 11:23:55 +02:00