it does indeed seem (as per the comment in CF) that CFE_SB_ReceiveBuffer guarantees that the msg/buf pointer will either:
1) definitely be valid (not NULL), if CFE_SB_ReceiveBuffer returns CFE_SUCCESS, or
2) definitely be NULL, if CFE_SB_ReceiveBuffer returns anything other than CFE_SUCCESS
Therefore, is this a situation where the code is being designed around the tests, rather than the other way around?
Can this check of the buffer != NULL be removed?
Note: the cFE core and most of the apps do not check the buffer for NULL when it's returned from CFE_SB_ReceiveBuffer with CFE_SUCCESS
This would also be an issue for achieving full MC/DC coverage no?
Expected behavior
Remove unnecessary conditions and unreachable paths.
Checklist
Describe the bug With regard to this comment: https://github.com/nasa/CF/blob/831fb16723b4b604c6f084fc9308ce1c33b7cd89/fsw/src/cf_app.c#L280-L284
Based on the logic here: https://github.com/nasa/cFE/blob/37f1d28df44aa7a858555b92f0c20310a6803b9f/modules/sb/fsw/src/cfe_sb_api.c#L1890-L1944 and a bit further down here: https://github.com/nasa/cFE/blob/37f1d28df44aa7a858555b92f0c20310a6803b9f/modules/sb/fsw/src/cfe_sb_api.c#L1989-L1993
it does indeed seem (as per the comment in CF) that
CFE_SB_ReceiveBufferguarantees that the msg/buf pointer will either: 1) definitely be valid (notNULL), ifCFE_SB_ReceiveBufferreturnsCFE_SUCCESS, or 2) definitely beNULL, ifCFE_SB_ReceiveBufferreturns anything other thanCFE_SUCCESSTherefore, is this a situation where the code is being designed around the tests, rather than the other way around?
Can this check of the buffer
!= NULLbe removed? Note: the cFE core and most of the apps do not check the buffer forNULLwhen it's returned fromCFE_SB_ReceiveBufferwithCFE_SUCCESSThis would also be an issue for achieving full MC/DC coverage no?
Expected behavior Remove unnecessary conditions and unreachable paths.
Reporter Info Avi Weiss @thnkslprpt