MISRA-C 2012 Compliance in kernel (kernel/*) and base OS code

[nashif]

Adhere to MISRA-C 2012 where it makes sense and provide deviations and documentation of rules we can't adhere to because of the nature of Zephyr.

[pfalcon]

@ceolin, So, what does MISRA says on addition of unsigned and signed integers (suppose of the same width)? I would expect to condemn that loudly, given that it's know to call for just crazy things. I'm looking for ally on reworking entire Zephyr timehandling API. In almost all places, we have signed values for elapsed time and delays, e.g.:

void _nano_sys_clock_tick_announce(s32_t ticks)

That doesn't make sense - the time goes only forward, so can't be negative. One possibility is that s32_t was used to limit the range of delays to INT_MAX (vs UINT_MAX), as crude way of dealing with overdue timeouts (detecting them). But non-negativity of e.g. delays aren't enforced, so nobody knows/can't know that max value of delays is INT_MAX.

Using signed stuff would invoke C undefined behavior, and could be killed on that regard, but cunningly, Zephyr doesn't use signed time everywhere, just in many cases.

This leads for example to u64_t += s32_t. I now hope that can be killed on MISRA C grounds.

(That all assumes that it can't be killed on the grounds of common sense, because if it could be, it wouldn't happen in the first place).

[ceolin]

@pfalcon Sorry for delaying this answer, I'm now jumping on it.
You're right, MISRA C has the "essential type" concept. Signed int (s32_t, s16_t ...) and unsigned int (u32_t, ...) have different "essential type" so it is not ok mix them (without explicit cast - case of signed to unsigned)

So, the u64_t += s32_t example, is NOT valid.

[ceolin]

@pfalcon one more thing, in general is safe presume that any undefined behaviour in C is doomed by MISRA-C