Skip to content
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

More consistent types for OSAL resources #635

Closed
jphickey opened this issue Oct 29, 2020 · 3 comments · Fixed by #654 or #662
Closed

More consistent types for OSAL resources #635

jphickey opened this issue Oct 29, 2020 · 3 comments · Fixed by #654 or #662
Assignees
Milestone

Comments

@jphickey
Copy link
Contributor

Is your feature request related to a problem? Please describe.
CFE issue nasa/cFE#663 describes mismatched types used across CFE for certain items, such as stack size and priority of tasks.
To help resolve this OSAL should provide a typedef for the "right" types to use when interfacing with OSAL.

Describe the solution you'd like
Should add at least:

  • osal_priority_t - type used for OSAL task priority
  • osal_stackptr_t - type used for OSAL stack pointer

Additional context
This will identify the correct type to use, instead of the mishmash currently seen in CFE as described in nasa/cFE#663.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

@jphickey
Copy link
Contributor Author

Question for @skliper and @acudmore --- OSAL also (still) uses uint32 for size everywhere. We already have a typedef for cpusize aka size_t - should I also update the OSAL APIs to use cpusize instead of uint32 in the APIs that accept a size?

@jphickey
Copy link
Contributor Author

Otherwise I can limit this to only fixing the type used for priority and the stack pointer (which only occur in a couple places).

jphickey added a commit to jphickey/osal that referenced this issue Oct 29, 2020
Adds typedefs for:

- osal_priority_t
- osal_stackptr_t

Note that by using `uint8` as the priority type, all values are
valid and it is no longer possible to pass a value which is out
of range.  Checks/tests for this are no longer valid and would
cause compiler warnings.
@skliper
Copy link
Contributor

skliper commented Oct 29, 2020

I'm good with the size change also.

jphickey added a commit to jphickey/osal that referenced this issue Nov 12, 2020
Adds typedefs for:

- osal_priority_t
- osal_stackptr_t
- osal_index_t
- osal_objtype_t

Note that by using `uint8` as the priority type, all values are
valid and it is no longer possible to pass a value which is out
of range.  Checks/tests for this are no longer valid and would
cause compiler warnings.
jphickey added a commit to jphickey/osal that referenced this issue Nov 16, 2020
Adds typedefs for:

- osal_priority_t
- osal_stackptr_t
- osal_index_t
- osal_objtype_t
- osal_blockcount_t

Note that by using `uint8` as the priority type, all values are
valid and it is no longer possible to pass a value which is out
of range.  Checks/tests for this are no longer valid and would
cause compiler warnings.
jphickey added a commit to jphickey/osal that referenced this issue Nov 17, 2020
Additional type corrections to avoid implicit sign
and width conversions.
astrogeco added a commit that referenced this issue Nov 21, 2020
Fix #635, Reduce use of uint32, add more OSAL typedefs
@skliper skliper added this to the 6.0.0 milestone Sep 24, 2021
jphickey added a commit to jphickey/osal that referenced this issue Aug 10, 2022
Manually merged to resolve conflicts.

From branch jphickey/fix-263-msgid-api:

Fix nasa#245, Consistent use of MsgId type
Fix nasa#263, Expose CFE_SB_IsValidMsgId() API

From branch dmknutsen/issue_240:

Fixes nasa#240, removes MESSAGE_FORMAT_IS_CCSDS ifdefs from code
jphickey pushed a commit to jphickey/osal that referenced this issue Aug 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants