Fix #387, Update minor out-of-family naming/consistency issues in CF

[thnkslprpt]

Checklist

• I reviewed the Contributing Guide.
• I signed and emailed the appropriate Contributor License Agreement to [email protected] and copied [email protected].

Describe the contribution

• Fixes Some minor out-of-family naming/consistency issues in CF could be updated #387
  • Add event for CreatePipe() failure during initialization (and created a new matching EID: CF_CR_PIPE_ERR_EID) + clarified different EIDs for pipe creation errors during initialization of the app, and separate EID for errors during CF Channel pipe creation (CF_CR_CHANNEL_PIPE_ERR_EID).
  • In CF_HkCmd(): Use CFE_SB_TimeStampMsg() instead of CFE_MSG_SetMsgTime() and use the CFE_MSG_PTR conversion macro - CF was the only app remaining to use CFE_MSG_SetMsgTime()
  • Add memset at the beginning of the initialization routine to zero-out the global data structure (defensive programming, and for consistency - almost all of the cFS modules/apps do this)
  • Remove check of the return value of CFE_EVS_SendEvent() reporting initialization success - this is very out-of-family for cFS and also inconsistent - CF does not check the return value of any other calls to CFE_EVS_SendEvent()
  • Remove null check in CF_AppMain() after successful call to CFE_SB_ReceiveBuffer() - out-of-family with cFS and also redundant (CFE_SB_ReceiveBuffer() with a successful return guarantees the returned pointer to be non-NULL)
     

Minor changes:

• Comment in CF_CmdAbandon_Txn() noted incorrect parameter cannot be NULL - corrected this
• Rename tlm_header to TelemetryHeader
• Rename run_status to RunStatus
• Rename cmd_pipe to CmdPipe
• Rename Software Bus command pipe message pointer variables (CFE_SB_Buffer_t types) from msg to BufPtr
• Rename msg_id to MessageID
• Move 'Cmd' to end of command function names (e.g. CF_CmdNoop() changed to CF_NoopCmd())
• Rename CF_CmdReset() to CF_ResetCountersCmd() - more clear and specific, and in line with vast majority of cFS incl. cFE (also amended the matching type CF_ResetCmd_t to CF_ResetCountersCmd_t)
• Rename CF_Init() to CF_AppInit()
• Removed a couple of unnessesasary header #includes - cf_verify.h in cf_clist.c and

Note: CF does not verify length for non-command MIDs received in the app pipe (CF_WAKE_UP_MID and CF_SEND_HK_MID) - it would be worthwhile to rectify this at some point.

cFE and the other apps are generally inconsistent on this - some don't check non-command MIDs, some use a single VerifyLength function to check all MIDs arriving, some use separate VerifyLength functions for command and non-command MIDs...

Testing performed
GitHub CI actions all passing successfully (incl. Build + Run, Unit/Functional Tests etc.).

Expected behavior changes
Minor changes as noted above, no significant changes to behavior.

Aligning aberrant naming to the predominant patterns in cFS improves usability and eases future maintenance.

Contributor Info
Avi Weiss @thnkslprpt

[github-advanced-security]

CodeQL found more than 10 potential problems in the proposed changes. Check the Files changed tab for more details.

[chillfig]

To safely remove the assignment to the status variable and maintain functional behavior, CFE_SUCCESS must be guaranteed at cf_app.c line 255. Is it?

Rationale given for removing the update of the status at that line is:

"this is very out-of-family for cFS and also inconsistent - CF does not check the return value of any other calls to CFE_EVS_SendEvent()"

However, examples of this check exist at:
https://github.com/nasa/HK/blob/406ec64b6428131230f2c9dac4f2f32452e04c7e/fsw/src/hk_app.c#L207

https://github.com/nasa/SCH/blob/dbaf51ebbcffe1177997880d0f555c7d489217f5/fsw/src/sch_app.c#L345

[chillfig]

@thnkslprpt Would you please expand on why the status init is removed here?

[thnkslprpt]

Yes correct - of the 10 main apps only HK and CF currently check the return of the CFE_EVS_SendEvent() reporting successful initialization. MD assigns it to the Result variable but does not report on failure. In cFE, only the SB module checks the return of this call to CFE_EVS_SendEvent(), all of the other modules do not do so.

In general, out of several thousand invocations of CFE_EVS_SendEvent() across cFS, its return value is only checked a handful of times. In CF specifically, there are 141 calls to CFE_EVS_SendEvent() (just in flight code) and this is the only place that the return value is assigned/checked.

If an app is already confirmed to be successfully registered with EVS (as is the case here), it's almost inconceivable that the call to CFE_EVS_SendEvent() will fail.

It seems undesirable for an app to exit (through failure of the init routine, and then setting RunStatus to CFE_ES_RunStatus_APP_ERROR) just because the event/notification of successful initialization failed for some reason (again, highly improbable if already confirmed registered with EVS).

This change is not essential (it can be left as it is) it's more just for the sake of consistency (almost all apps and cFE modules just call CFE_EVS_SendEvent() to report successful initialization, without checking its return value or assigning it to their Status/Result variables).

[skliper]

For length check and command handling inconsistencies, hopefully nasa/cFE#2038 will eventually resolve this across all of cFS.

[chillfig]

Concur with changes and justification for check return value omission is appreciated. Although, as discussed at the 6/22/2023 cFS community board, cFS is a community-built product with many developers who worked different apps and so it may be unwise to always use justification of consistency to make all the submodules/apps of cFS behave the same.

[github-advanced-security]

CodeQL-coding-standard found more than 10 potential problems in the proposed changes. Check the Files changed tab for more details.

[thnkslprpt]

Concur with changes...

@chillfig Justin - slight change since your approval due to a merge conflict resolution. There are now 2 separate EIDs for the different pipe creation error locations: CF_CR_CHANNEL_PIPE_ERR_EID and CF_CR_PIPE_ERR_EID

[jphickey]

I like this changeset, but it overlaps with other recent PRs. We should rebase it, but only after the other pending items.

[thnkslprpt]

I like this changeset, but it overlaps with other recent PRs. We should rebase it, but only after the other pending items.

No worries Joe @jphickey - I'll try to keep it up-to-date. Feel free to merge it whenever it suits.

[dzbaker]

Hi @thnkslprpt, apologies about the delay with this PR. I'd like to get it into the next round of PR reviews. Would you be able to resolve the merge conflict/unit test workflow failure?

[thnkslprpt]

Hi @thnkslprpt, apologies about the delay with this PR. I'd like to get it into the next round of PR reviews. Would you be able to resolve the merge conflict/unit test workflow failure?

I think it's good to go now @dzbaker