Header structure name assumptions limit MSG abstraction capability

[jphickey]

Is your feature request related to a problem? Please describe.
The MSG library is supposed to offer a complete abstraction of the header format, but in practice there are still some direct references to header structure members in Caelum which limit this capability.

In particular, when converting a local message buffer to a CFE_MSG_Message_t pointer, when passing into any CFE_SB API, the code references a sub-member, such as:

cFE/modules/es/fsw/src/cfe_es_task.c

Line 396 in 64a6a59

CFE_MSG_Init(&CFE_ES_Global.TaskData.HkPacket.TlmHeader.Msg, CFE_SB_ValueToMsgId(CFE_ES_HK_TLM_MID),

While this was nice in that it is fully type-safe, it limits the header abstraction in two important ways:

1. It assumes/requires that the buffer itself contains a TlmHeader member.
2. It assumes/requires that the TlmHeader structure, in turn, contains a .Msg member.

For item (2) above, the TLM header is a structure controlled/defined by the CFE_MSG module, and there is no guarantee that a "Msg" member exists. This will be a problem if an alternate MSG module is used, where the CFE_MSG_Message_t member is not called "Msg". (The whole point of MSG is to make these structures free-form, and no assumptions should be made as to their internal structure, so this reference somewhat defeats that purpose).

Describe the solution you'd like

• Convert this to a cast instead, e.g. (CFE_MSG_Message_t*)&CFE_ES_Global.TaskData.HkPacket
• Have CFE_MSG provide a macro/inline function to implement this conversion/cast

Describe alternatives you've considered
Just document what the names need to be, and make it a requirement to name things in this manner.

Major issues with that - mainly that it is not friendly to automated tools which might be used to generate these headers/structures from a CMD/TLM database.

Additional context
There is no real convention to the names that exist today. It would be more viable to do that if a specific convention/reasoning was followed, such as the CFE_MSG_Message_t member being called Message (i.e. without the CFE_MSG_ prefix or _t suffix). This way a tool would know what name to call things in the generated files. But as it is, there is simply no naming consistency in these members, a tool would have to hard-code "special" member names for each structure, for no good reason other than that's what a human had used for an abbreviation at one point.

But furthermore, even if a name convention was follwed prevents an additional layer of headers to be added. For example, the "TlmHeader" is assumed contain a "Msg" member directly. However in some implementations a user might want an intermediate header, where it would become .TlmHeader.Intermediate.Msg instead. There is no way to accommodate a third layer with the current assumptions in the code.

Regarding suggested casts -- by casting, it can be converted without knowing what the member is specifically named, nor knowing how deep within the structure the Message structure lies. This is not as bad as it sounds, and not really going back to being type-unsafe, because it is being cast to a CFE_MSG_Message_t*, not a void* as previous CFE versions had done here. Because of this, and the fact that CFE is compiled with strict aliasing rules enabled, it will trigger an alias violation if the structure is not actually cast-able to a CFE_MSG_Message_t type. While this is not quite as robust as the current type safety, it is much more flexible, and user errors/mismatches should still be caught.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

Also worth noting that the SB code still has some references to CCSDS_SpacePacket_t around, which also limits the abstraction. These should probably be fixed to reference CFE_MSG_Message_t instead.

[jphickey]

Another "compromise" option might be to enforce a name convention, but only on the first/top level element, and make it work with a type safe inline function, without resorting to casts.

For example, if the convention was used where the name of the member is prescribed as the name of the MSG type without the CFE_MSG_ prefix nor the _t suffix, all CFE code would then need to define its member as CommandHeader and TelemetryHeader, respectively. This would be a change to all modules (most use TlmHeader, but SB uses just Hdr - this would have to all be corrected to follow convention).

Then, a pair of type-safe inline conversion functions can be made, to convert a CFE_MSG_TelemetryHeader_t or CFE_MSG_CommandHeader_t to a CFE_MSG_Message_t. This conversion would be part of MSG, so it would correlate to however MSG has defined the headers.