-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split "ResourceId" type into a separate module #1108
Comments
Note - this was mentioned/brought up during the review of #1092 in CCB 2021-01-13 |
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Jan 26, 2021
Move all functions, macros, types, and other definitions related to resource IDs and generic resource management into a separate module, like CFE MSG and SBR, etc. Notably this allows a mission to elect "strict" implementations of these objects, where every ID type is unique, and assigning between them (or uint32) results in a compiler error.
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Jan 27, 2021
Move all functions, macros, types, and other definitions related to resource IDs and generic resource management into a separate module, like CFE MSG and SBR, etc. Notably this allows a mission to elect "strict" implementations of these objects, where every ID type is unique, and assigning between them (or uint32) results in a compiler error.
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Feb 1, 2021
Remove code blocks that were commented out, not needed.
jphickey
added a commit
that referenced
this issue
Feb 8, 2021
Fix #1108, split resource id functions into module
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
The
CFE_ES_ResourceId_t
type is currently defined by ES, but in issue #985 and PR #1092 this was extended to be used by SB. There is also a potential to use it for TBL handles as well.There is also some choice here - in that the
CFE_ES_ResourceID_t
type can be a simple typedef touint32
for compatibility, or a type-safe wrapper to make sure it doesn't get mixed.Describe the solution you'd like
Put the type definition and associated access functions/macros/constants into a separate CFE module, like
msg
andsbr
are currently done. This gets it out from being an "ES" type, extending it apply to all of CFE core and possibly also apps.Additional context
This also can incorporate a solution for #913 - each app may specialize the generic type with its own typedef.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: