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
Is your feature request related to a problem? Please describe.
A CFE_SB_MsgId_t value, like other IDs, is supposed to be a unique type/opaque value that identifies a message within the SB application context. Although it is currently implemented using an integer (uint32 specifically) application should not assume this. Instead, a set of macros and inline conversion functions (CFE_SB_MsgIdToValue and CFE_SB_ValueToMsgId) are provided for when the application needs to interpret the value as an integer for a valid purpose.
However, since use of this conversion is not currently enforced - there is no config option that makes MsgId into a strict type, as there is for ResourceID - so much of the newly-added code such as tests and apps, didn't completely apply it.
Describe the solution you'd like
Add conversions where they are currently missing
Describe alternatives you've considered
Preferably, the MID constants should be defined directly as a CFE_SB_MsgId_t type value, which would eliminate the need for conversions all over the runtime code. However, this breaks the switch/case paradigm used when dispatching - a case label needs to be an integer value. So although this would yield cleaner code it does have a bigger backward compatibility impact which is why it was avoided for Caelum.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered:
Correct code that was not correctly using the CFE_SB_ValueToMsgId or
CFE_SB_MsgIdToValue conversion wrappers where required to do so. This
should be used whenever the value is intentionally converted to/from
an integer. The CFE_SB_MsgId_t type should not be assumed to be
an integer in nature.
Correct code that was not correctly using the CFE_SB_ValueToMsgId or
CFE_SB_MsgIdToValue conversion wrappers where required to do so. This
should be used whenever the value is intentionally converted to/from
an integer. The CFE_SB_MsgId_t type should not be assumed to be
an integer in nature.
Is your feature request related to a problem? Please describe.
A
CFE_SB_MsgId_t
value, like other IDs, is supposed to be a unique type/opaque value that identifies a message within the SB application context. Although it is currently implemented using an integer (uint32
specifically) application should not assume this. Instead, a set of macros and inline conversion functions (CFE_SB_MsgIdToValue and CFE_SB_ValueToMsgId) are provided for when the application needs to interpret the value as an integer for a valid purpose.However, since use of this conversion is not currently enforced - there is no config option that makes MsgId into a strict type, as there is for ResourceID - so much of the newly-added code such as tests and apps, didn't completely apply it.
Describe the solution you'd like
Add conversions where they are currently missing
Describe alternatives you've considered
Preferably, the MID constants should be defined directly as a
CFE_SB_MsgId_t
type value, which would eliminate the need for conversions all over the runtime code. However, this breaks the switch/case paradigm used when dispatching - acase
label needs to be an integer value. So although this would yield cleaner code it does have a bigger backward compatibility impact which is why it was avoided for Caelum.Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: