Add assertions and casts to implicit integer demotions.

[jvalenzuela]

No description provided.

[MartinMelikMerkumians]

Please no asserts in code other than startup code, as these can then be used as attacks to crash OpENer.
I know, I have them still in parts of the code, but since security issue reports, I do not add new ones.
If the sanity check is necessary, please change the function to return a boolean flag to indicate if the sanity check failed.

[jvalenzuela]

I agree an assertion is the wrong reaction to a failure during startup which prohibits the program from operating correctly, e.g., malloc failure. The program should return a non-zero exit code, perhaps with a message to stderr, not assert. However, assertions do have their place, and not limited to any particular phase. They should only be used to detect situations that are unquestionably bugs and likely to cause erratic or undefined behavior if the program continues. Examples are dereferencing a NULL pointer or divide by zero. A good indication if an assert is merited is if the program is permitted to continue it would probably crash or become unstable without the assertion. In those cases the assertion provides a debugging method to reliably catch the condition. Such cases should never arise from any form of external input, which could manifest as a security issue as you stated; all external input should be vetted by normal, run-time checks, not assertions.

If you concur, then I think this commit is still valid in that context. The arguments to CipEpathSetLogicalValue should already be validated before being passed to this low-level function. Receiving a logical_value parameter exceeding the target integer witdth is an obvious bug, just like an undefined logical_format value.

[jvalenzuela]

In addition to the comments above, the benefits of assertions can be retained without causing explicit crashes by redefining OPENER_ASSERT to an empty statement when compiling production software.

[MartinMelikMerkumians]

After giving this more thought, I agree with you, but I think the asserting/non-checking behavior should probably be added to the doxygen documentation

[jvalenzuela]

Do you mean a general discussion of proper assert usage, or comments specific to the assertions added in this commit? If the former, which I think would be a good idea, do you think it should go in doxygen or the coding rules document(LaTeX)?

[MartinMelikMerkumians]

In general and putting comments into the code documentation, not necessarily in this commit. Good idea on making general rules. Guess they should go into the coding rules.