search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
9.74k stars 6k forks source link

lib: added parentheses verifying the lack of ambiguities #72213

Open DeHess opened 2 weeks ago

DeHess commented 2 weeks ago

Fix coding guideline MISRA C:2012 Rule 12.1 in lib:

The precedence of operators within expressions should be made explicit.

This PR is part of the enhancement issue https://github.com/zephyrproject-rtos/zephyr/issues/48002 which port the coding guideline fixes done by BUGSENG on the https://github.com/zephyrproject-rtos/zephyr/tree/v2.7-auditable-branch back to main

The commit in this PR is a subset of the original auditable-branch commit: https://github.com/zephyrproject-rtos/zephyr/commit/29155bdd6c8f8c2c0bdf0562191b4b968b3a818a

keith-packard commented 2 weeks ago

I'm usually in favor of extra parens so we don't have to remember all of the C precedence levels, but do we really need parens around (a * b) + c too? Or (a + b) >= c? At some point, it does get a bit chatty.

simhein commented 1 week ago

I'm usually in favor of extra parens so we don't have to remember all of the C precedence levels, but do we really need parens around (a * b) + c too? Or (a + b) >= c? At some point, it does get a bit chatty.

@keith-packard Thanks for your Feedback. I generally agree that this gets chatty in some way. On the other hand I don't know a way to partially use this guideline to be honest. If we check that guideline with a tooling, than the tooling gets very chatty and complain about it every time, to solve this we need to add something in the code which makes the code not that readable which I want to avoid. I will keep that topic in mind and look into it to find a way how we can maybe handle such things in future.