CFE_SB_GetLastSenderID will crash if if called before message sent on pipe

CFE_SB_GetLastSenderID assumes that CFE_SB.PipeTbl[PipeId].CurrentBuff is not NULL. Upon CFE_SB_CreatePipe, this will be null. CurrentBuff is only set upon receiving a message in CFE_SB_RcvMsg(). So, if CFE_SB_GetLastSenderID is called before receiving a message the program will crash.

This is Steven Seeger from GSFC. Guess I have a personal account on github. :)

[jwilmot]

This should be fixed. A user application error (last sender API called early) should not cause the cFE to crash. Recommend returning error and setting last sender to a known invalid id. uint32 0xFFFFFFFF is a possible choice.

[jphickey]

Please note that with respect to the "invalid message id" notion, there are a at least two other other related changes waiting in the wings that should be coordinated with this:

1. expose CFE_SB_IsValidMsgId() #263 is to provide a CFE_SB_IsValidMsgId() function in the public SB API (currently private for some unknown reason)
2. Type safety and improved handling of CFE_SB_MsgId_t values #245 is to provide type safety for CFE_SB_MsgId_t so it isn't a "bare number" that can be interchanged with other integers.

Lastly, note that there is an existing definition for an invalid CFE_SB_MsgId_t value, and it is currently:

#define CFE_SB_INVALID_MSG_ID           0xFFFF /**< \brief Initializer for CFE_SB_MsgId_t values that will not match any real MsgId */

In particular I'm bringing all this up because one must resist the temptation to do something like:
if (MsgId == CFE_SB_INVALID_MSG_ID).... bur rather the SB API function should be used to test the MsgId.

And secondly don't assume CFE_SB_MsgId_t will always remain a simple integer. Assignments are OK (i.e. MsgId = CFE_SB_INVALID_MSG_ID will need to work) but addition/subtraction/comparison may NOT work. Testing and manipulation of the value should always go through the SB API.