Alignment warnings when casting char* pointers #437
Labels
Milestone
Comments
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Dec 20, 2019
On CPUs with strict alignment requirements, some CFE code that uses a char-type pointer (e.g. uint8*) to compute memory addresses triggers an alignment warning when it gets cast back to the actual data type. This code should be alignment-safe already, because the address computation already takes CPU alignment requirements into account when calculating the addresses/offsets. However, the compiler still flags the final conversion from a pointer with no special alignment to something with alignment requirements. - For the CFE_SB pool buffers, using the `cpuaddr` type, which is integer in nature, avoids the warning. - For the CFE_TBL internal table pointer, use a `void*` internally to store the buffer pointer, rather than a `uint8_t*`. This changes the casting needs elsewhere.
This was referenced Jan 3, 2020
skliper
pushed a commit
that referenced
this issue
Jan 10, 2020
On CPUs with strict alignment requirements, some CFE code that uses a char-type pointer (e.g. uint8*) to compute memory addresses triggers an alignment warning when it gets cast back to the actual data type. This code should be alignment-safe already, because the address computation already takes CPU alignment requirements into account when calculating the addresses/offsets. However, the compiler still flags the final conversion from a pointer with no special alignment to something with alignment requirements. - For the CFE_SB pool buffers, using the `cpuaddr` type, which is integer in nature, avoids the warning. - For the CFE_TBL internal table pointer, use a `void*` internally to store the buffer pointer, rather than a `uint8_t*`. This changes the casting needs elsewhere.
skliper
pushed a commit
that referenced
this issue
Jan 10, 2020
On CPUs with strict alignment requirements, some CFE code that uses a char-type pointer (e.g. uint8*) to compute memory addresses triggers an alignment warning when it gets cast back to the actual data type. This code should be alignment-safe already, because the address computation already takes CPU alignment requirements into account when calculating the addresses/offsets. However, the compiler still flags the final conversion from a pointer with no special alignment to something with alignment requirements. - For the CFE_SB pool buffers, using the `cpuaddr` type, which is integer in nature, avoids the warning. - For the CFE_TBL internal table pointer, use a `void*` internally to store the buffer pointer, rather than a `uint8_t*`. This changes the casting needs elsewhere.
skliper
added a commit
that referenced
this issue
Jan 14, 2020
Fix #437: Avoid alignment warnings on some CPUs
This was referenced May 5, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When compiling on architectures with strict alignment requirements, casts between
char*(as used in some pointer arithmetic to calculate addresses) to other types triggers a warning about alignment.To Reproduce
Build for an architecture with strict alignment requirements (SPARC, MIPS, etc).
Example compiler warning:
Expected behavior
Should build cleanly with no warnings
System observed on:
Additional context
Many of these are actually safe because CFE ensures that the
sizeof(CFE_SB_BufferD_t)as well as the base/pool addresses are aligned for the largest data types. However, because the pointer arithmetic is done as aunsigned char*the compiler sees the cast from anunsigned char*to a larger type as an issue.Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: