Add compile time assert that int size is 32 bit

[skliper]

Is your feature request related to a problem? Please describe.
Per discussion 2/26/2020 there's likely breakage in multiple places on a system where int != 32 bit (standard minimum is 16 bit)

Describe the solution you'd like
Along with #204, cFE not really designed to work on a system without char of 8 bit size and int of 32. Enforce/warn on build.

Describe alternatives you've considered
Improve documentation? Still nice to bail on compile for those who don't read documentation.

Additional context
#504, and many other places convert int32 to int or the unsigned equiv.

Requester Info
Jacob Hageman - NASA/GSFC

[jphickey]

There really shouldn't be an issue running on a system where int is only 16 bits because the code uses int32 and uint32 precisely for this reason, except where interaction with the system library requires 'int'.

Many printf style calls do contain a force cast to int to be compatible with %d, but this could be changed to long and %ld instead. There should never be an unintended truncation if casting a [u]int32 type to a long type, because long is guaranteed to be at least 32 bits.

My preference is to still avoid asserting on items that aren't known to be problems. In this case it is just that we haven't really tested it, not that it doesn't work.

[skliper]

Many printf style calls do contain a force cast to int to be compatible with %d, but this could be changed to long and %ld instead. There should never be an unintended truncation if casting a [u]int32 type to a long type, because long is guaranteed to be at least 32 bits.

My preference is to still avoid asserting on items that aren't known to be problems. In this case it is just that we haven't really tested it, not that it doesn't work.

You describe a known problem with truncation due to casting and then claim there isn't a known problem. I don't follow this logic. There is a known problem, lets add an assert.

[jphickey]

Because the better solution is to use %ld/long and %lu/unsigned long casts, rather than asserting on something that isn't really a problem, and unnecessarily limiting the software for not a good reason.

I don't like compile time asserts, and especially so when they aren't really a fundamental problem.

[skliper]

I agree there are better solutions, but at such a low priority I don't see it getting resolved soon. It seems prudent to notify a user of the current issue on such a system. Maybe @acudmore or @jwilmot could weigh in. I'd prefer a check along with a response that systems with int of size < 32 bits could encounter truncation due to type casting of 32 bit types to int. I'd rather be obvious about the current issue than not-so-obvious issues if used on this sort of system. A user could always remove the assert if they so chose.

Lacking the obvious assert, users could head down a rat hole or run in to not-so-obvious bugs. I'm not following why this should be the preferred approach.

[jphickey]

Yes I agree its low priority, but I'd rather not forcibly break the build on someone just because we haven't explicitly tested the software using their configuration, especially when there is a real fix for the known issue.

The truncation issue is a minor one as it only affects printfs, and only if the value actually exceeds int at runtime. The code might still run OK otherwise. Hardly worth a hard-stop on preventing someone from even building the code in that config.

Compile-time asserts should be reserved for items which are known to be truly incompatible with the architecture. We cannot assert against every system/config variation we haven't tested or for which there might be a potential issue or an open bug.

This seems like more appropriate for release notes and documentation, not a compile-time assert.