Avoiding Struct-Padding in cFS

[jeffstjean]

I know OS_PACK was removed in earlier versions (for better compiler support?). It seems as though most cFS apps have switched to manually aligning their structs. Is this the "cFS-way" of eliminating padding?

Is there an easy way to check that padding has been done correctly (aside from static_assert() that the sum of all members are equal to the size of the struct)?

I know there isn't a portable way to restrict padding, I wanted to check if manual padding is the method cFS and cFS apps have chosen?

[BBinLP]

Manual padding seems to make the most sense because it also makes it easier to format the ground system artifacts that describe telemetry and command packets. On our latest mission, we check that padding is appropriate and that the packet is at least on a word boundary with a unit test. #define UTASSERT_DIAGPKT_OFFSET(ElementNameToCheck) \ ActualOffset = (uint32)((uint8 *)&DiagPkt.ElementNameToCheck - PktZeroOffset); \ UtAssert_True(ExpectedOffset == ActualOffset, #ElementNameToCheck " is at <%d>, expected <%d>", ActualOffset, \ ExpectedOffset); \ ExpectedOffset += sizeof(DiagPkt.ElementNameToCheck) void UT_TlmPadding_Diagnostic_Eval(void) { DiagPkt_t DiagPkt; uint32 ExpectedOffset = sizeof(DiagPkt.TlmHeader); uint8 * PktZeroOffset = (uint8 *)&DiagPkt.TlmHeader; uint32 ActualOffset = 0; UTASSERT_DIAGPKT_OFFSET(MeasTime); UTASSERT_DIAGPKT_OFFSET(OnTime); UTASSERT_DIAGPKT_OFFSET(Status); UTASSERT_DIAGPKT_OFFSET(Cnts); UTASSERT_DIAGPKT_OFFSET(DeltaCnts); UTASSERT_DIAGPKT_OFFSET(TotalCycles); UTASSERT_DIAGPKT_OFFSET(VCnts); UTASSERT_DIAGPKT_OFFSET(DeltaV Cnts); UtAssert_True(ExpectedOffset == sizeof(DiagPkt), "Diag Tlm packet size is <%u>, expected<%u>", sizeof(DiagPkt), ExpectedOffset); UtAssert_True(sizeof(DiagPkt) % 2 == 0, "Diag Tlm packet size is on a word boundary, size is <%u>", sizeof(DiagPkt)); }

…

On Thu, Aug 18, 2022 at 8:56 PM Jeff St. Jean ***@***.***> wrote: I know OS_PACK was removed in earlier versions (for better compiler support?). It seems as though most cFS apps have switched to manually aligning <https://github.com/nasa/CS/blob/draco-rc2/fsw/src/cs_msg.h#L53> their structs. Is this the "cFS-way" of eliminating padding? Is there an easy way to check that padding has been done correctly (aside from static_assert() that the sum of all members are equal to the size of the struct)? I know there isn't a portable way to restrict padding, I wanted to check if manual padding is the method cFS and cFS apps have chosen? — Reply to this email directly, view it on GitHub <#548>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKJGI2ENAKNGKTXF475NLOTVZ3LSXANCNFSM567AVDEA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jeffstjean]

We've never really had any issues with alignment and padding on the ground side, although I can see why that may be helpful. Interesting way to use unit tests to check if the alignment is correct.

Is there any downside to using a compiler extension aside from some potential marginal performance hits and being locked into a certain compiler?

[irowebbn]

GCC and Clang have -Wpadded which will warn about compiler-inserted padding into structs. libclang also has some nice tools for looking at the layout of records that you can use to identify padding (one example is here, although I prefer to use the Python bindings). I've used that approach to generate ground tool layouts that accounted for the hidden padding since we didn't pack our messages before serializing them on the wire.