Fix #705, Use cFE defines to size arrays

[skliper]

Describe the contribution
Fixes #705, also a similar issue in TBL
Change from OS_MAX* defines to CFE defines for array sizing

Testing performed
Built and ran unit tests, passed. Visually confirmed sizes matched.

Expected behavior changes
No impact as long as the sizes are the same. Now scoped appropriately such that OS's can be configured differently and won't break cFE (as long as the cFE defines are max of the set)

System(s) tested on

• Hardware: cFS Dev Server
• OS: Ubuntu 18.04
• Versions: bundle main + this commit

Additional context
None

Third party code
None

Contributor Info - All information REQUIRED for consideration of pull request
Jacob Hageman - NASA/GSFC

[jphickey]

Seems like there is more work to do here.... ?

• As the structures (CFE_ES_AppInfo_t) are actually part of the IPC interface (msg), the definition of these shouldn't be in cfe_es.h but rather in cfe_es_msg.h where all other structures used within messages are defined.
• Anywhere that the Name, EntryPoint, or FileName members are filled should use CFE_SB_MessageStringSet- which is similar to strncpy but takes both a source and dest length. It is intended for this use case where the local/platform and global/mission sizes might be different and this handles padding/termination issues.

[skliper]

Seems like there is more work...

I suggest new issue(s) since at least the second change sounds like a useful one to get documented separately, the old one just covered the array sizing.

[CDKnightNASA]

FYI given this development, I'm wondering of the wisdom of having return status int32's intermixing CFE and OSAL return status...I realize that'll mean a lot of duplication where we remap OSAL status to CFE status with the same name, but in a lot of cases I'm guessing CFE can simplify the return status.

[astrogeco]

CCB 2020-09-23 write up extra issues based on conversation. @jphickey to update function calls.

[skliper]

FYI given this development, I'm wondering of the wisdom of having return status int32's intermixing CFE and OSAL return status...I realize that'll mean a lot of duplication where we remap OSAL status to CFE status with the same name, but in a lot of cases I'm guessing CFE can simplify the return status.

Is this in reference to a different issue? This just changed array sizes...

[CDKnightNASA]

FYI given this development, I'm wondering of the wisdom of having return status int32's intermixing CFE and OSAL return status...I realize that'll mean a lot of duplication where we remap OSAL status to CFE status with the same name, but in a lot of cases I'm guessing CFE can simplify the return status.

Is this in reference to a different issue? This just changed array sizes...

Just saying, philosophically we are "divorcing" array sizes from OSAL defs, while we continue to be "married" to the OSAL return codes. :) A general philosophical matter but one I think is a bit of conflict.

[jphickey]

@skliper - My suggested update to fix the output sizes is here: skliper/cFE@fix705-rm-os-dependence...jphickey:fix-705-outarray-size

If you want, you can either merge this into your PR or I can submit a new PR that has both.

To summarize, I decided against using CFE_SB_MessageStringSet() because it (intentionally) fills the output buffer completely, foregoing a null terminator if it doesn't fit. But due to the usage patterns of these structs we should always ensure null termination. So continuing to use the C library strncpy() routine is no worse, we just have to make sure to use sizeof() rather than assume a specific macro/symbol.

[astrogeco]

CCB 2020-09-30:

• There are some cases where we'll get unit test failures, changeing cFE defined OS_size
  • @skliper open new ticket to fix

APPROVED

[astrogeco]

@skliper can you clear the conflicts?

[skliper]

@astrogeco conflicts resolved.

Reviewed at CCB