I've written this email two days ago and somehow it never left my
outbox so I'm re-sending it because I think it is still relevant.
Well if code quality is truly the only goal of the steering committee and
there's no politics involved then I retract everything I said. Misra offers
less than nothing for this project. But I don't believe that's true. This is
100% politics if you ask me.
We should keep this discussion as much technical as possible. The code
guidelines rules we are following were discussed in the past involving
the whole community and not by small group of people.
That's being said, they are not written in stone, we can review them to
add changes or completely remove if we want, just open an issue and
expose technical reasons.
I really don't get this statement "offers less than nothing for this
project" ... Most MISRA guidelines address undefined / unspecified
behaviors in the C language. For a project that aims to support multiple
compilers and platforms this seems to be a good thing.
Also before declaring the virtues of Misra, you'll be sure to clarify any
vested financial interest you might have in the matter, right? You know, just
to make sure you're not shilling.
Abramo is putting technical arguments to justify the changes, please
challenge the arguments. Everyone here has its own interests.
On Mon, Dec 13, 2021, 9:38 PM Abramo Bagnara <abramo.bagnara@...>
Il 13/12/21 04:37, Nicolas Pitre ha scritto:
> I've also seen too many times a bug being introduced because the code
> was modified just to make it [name your favorite static analysis tool /
> coding standard here]-compliant. It is often the case that the code is
> questionnably written in the first place, and adding typecasts to it
> makes it worse even if the scanning tool is then happy.
I'd like make clear once and for all that the happiness of scanning tool
is *never* a valuable purpose under a MISRA perspective.
What matter is *only* the quality of code and MISRA is a tool to achieve
Il 13/12/21 04:37, Benjamin Lindqvist ha scritto:
> Hopefully most people in the community agree that many, if not most,
> Misra rules are outdated or even slightly harmful. But you optimize
> with the constraint being the way the world works, not how it should
> ideally work. If this is what it takes to get zephyr backed by Daimler
> and Volvo, I for one can't blame the steering committee for thinking
> the tradeoff is justified. I'd do the same thing probably, despite
> loathing Misra with all my heart.
In my experience this is a consequence of a misunderstanding of what
MISRA really is.
MISRA process has rules, but also deviations and permits and the only
sane way to use it is as a tool to improve
Please forget every other idea of it as an enemy to beat or to surrender
As Nicolas has already done you are welcome to point out *any* proposed
change related to MISRA compliance that you think will make code worse
together with an alternative proposal to improve code at the same time.
I hope this will clarify that everyone in the community has the same
code improvement goal and, as usual, constructive collaboration is the key.
BUGSENG srl - http://bugseng.com