VxWorks stack address calculation should use unsigned type #651
Comments
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Nov 17, 2020
This should avoid any inconsistencies in the event that the memory address translates to a negative numeric value.
astrogeco
added a commit
that referenced
this issue
Dec 1, 2020
Fix #651, use unsigned types in VxWorks stack calculation
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Aug 10, 2022
Instead of identifying a memory pool by its memory address, use a resource ID. IDs are a constant size, regardless of whether the host machine is 32 or 64 bits. - IDs can be put into commands/telemetry and maintain a more consistent format with consistent alignment requirements. - IDs can be independently verified without dereferencing memory. Previously the only way to validate a memory pool was to read the address pointed to, which results in a SEGV if the address was bad.
jphickey
pushed a commit
to jphickey/osal
that referenced
this issue
Aug 10, 2022
Fix nasa#651, Use resource ID for memory pools
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 VxWorks task create implementation calculates a stack base address which involves adjustment such as rounding and accounting for whether the stack grows up or down (per VxWorks requirements of
taskInit().This does the calculation as integers, and currently uses the
longtype.The risk is that if the address happens to lie in the negative range of this type, then the rounding/adjustments may need to go in the opposite direction.
Describe the solution you'd like
The address calculations should use
unsigned longinstead oflongjust to ensure that all rounding and base address adjustments behave the same way in the event that the addresses lie in the upper half of memory (i.e. start with a 1 bit) which would put it in the negative range of alongtype.Additional context
This is really just a suspicion of a possible issue - can't really confirm/test because we don't have direct control of where these stack buffers get allocated in memory.
But either way using
unsignedwould be more correct anyway - and would simply avoid the possibility that the operation works differently depending on its value.It probably used
longin the first place only because that is what the arguments totaskInit()are declared as.Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: