Type-safe implementation for osal_id_t #1208
Labels
Milestone
Comments
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Jan 18, 2022
Modifies the osal_id_t typedef to be a non-integer value. The intent is to catch cases where it inappropriately being used as an integer value. This is transparent so long as the osal_id_t typedef and provided check and conversion routines are used.
astrogeco
added a commit
that referenced
this issue
Jan 24, 2022
Fix #1208, typesafe definition of osal_id_t
astrogeco
added a commit
that referenced
this issue
Jan 24, 2022
Fix #1208, typesafe definition of osal_id_t
jphickey
pushed a commit
to jphickey/osal
that referenced
this issue
Aug 10, 2022
jphickey
pushed a commit
to jphickey/osal
that referenced
this issue
Aug 10, 2022
Fix nasa#1208, Cast isspace input to unsigned char
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
osal_id_ttype is currently just a plainuint32to make it backward-compatible. The problem is that a plain number does not convey the purpose/intent of this ID value. Users can still do things like addition, subtraction, or interchange with other numbers, which are all invalid for a number being used as an ID.As long as users are using the
osal_id_ttype and the associated checks/conversions also provided by OSAL (e.g. OS_ObjectIdDefined, etc) then this should be transparent.Describe the solution you'd like
Make
osal_id_ttype-safeAdditional context
This was the intent all along with creating a separate
osal_id_ttypedef and using it across the CFE and PSP.It does depend on having all the dependent code using the typedef, so probably want to stage this in using OSAL_OMIT_DEPRECATED flag or similar, so we can find the things that are still broken in this regard.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: