Nicolas Pitre <nico@...>

I appreciate your points, and similarly for a few others before yours,
but I think they are missing the point.

No one is against virtue.

Everybody wants the code base to be more consistent, more secure, etc.

But mechanically making the code MISRA compliant doesn't achieve that.

I persist in insisting that adding any more typecasts to a codebase
makes it worse. Typecasts should be _removed_ as much as possible, not
added. Thinking about how to avoid a cast produces better code almost
all the time. I would hardly trust "compliant" code for safety critical
applications if compliance came about due to added typecasts.

Same thing for qualifying literals as unsigned. I made the demonstration
already showing how evil that is. And no, just saying that the MISRA
scan tool will spot mixed signedness and complain -- that's also missing
the point. It is just safer, clearer, lighter and more enjoyable to just
_not_ qualify literals when not required, and let the compiler promote
expressions to unsigned when the semantic-carrying non-literal part is
unsigned, at which point you don't need a tool to spot mixed signedness
because they're just OK. For those rare cases where mixed signedness is
bad there are tricks to spot them e.g. look at the Linux min() and max()
implementations where the constraint is encapsulated in one place and
not spread all over the entire code.

Avoiding so called "undefined" syntax when all existing compiler
implementations handle many of them just fine is stupid. Usually there
is a couple reasons why compilers still implement some "undefined"
behaviors: it is totally logical, uncontroversial, and also useful by
making the code clearer and easier to maintain. Instead of banning them
outright, we should instead implement a test safeguarding our reliance
on them.

I don't care about braces everywhere. Well, that's not true: I do hate
them, but that I can live with and there is a technical argument in
favor of them and no real technical arguments against.

Etc. Etc.

So let's stop thinking that XYZ conformance automatically makes the code
intrinsicly better. It doesn't. It may bring a false sense of security

On Wed, 15 Dec 2021, Gerard Marull Paretas wrote:

A few points from my side (probably nothing that has not been already said)

- MISRA mostly tries to avoid undefined behavior derived issues. Other
languages such as Rust have done a better job on this topic from the very
- Not all rules are mandatory to make a codebase MISRA compliant, so a
project can decide to deviate where it makes sense.
- If seeking for MISRA compliance, the coding style used by a project
needs to introduce certain rules (e.g. if always needs to use braces). From
my perspective this is not a problem, I, personally, prefer consistent
codebases even if they have certain rules I'm not 100% happy with. If we
take for example the STM32 HAL (which is MISRA C 2012 compliant) one will
observe that code is much more consistent compared to Zephyr. Nowadays,
Zephyr just runs checkpatch, which loosely enforces Linux Kernel coding
- Zephyr has the potential to target safety critical applications, so I
think it makes sense to certify core parts of the project. Without that,
there are markets that are simply out of the game. This is likely not a
concern for Linux.


On Wed, Dec 15, 2021 at 2:35 PM Nashif, Anas <anas.nashif@...> wrote:


Point taken, will start posting agenda the day before.


*From: *devel@... <devel@...> on
behalf of Olof Johansson <olof@...>
*Date: *Wednesday, December 15, 2021 at 2:14 AM
*To: *Hibberd, Amber M <amber.m.hibberd@...>
*Cc: *Abramo Bagnara <abramo.bagnara@...>, Benjamin Lindqvist <
benjamin.lindqvist@...>, Kevin Hilman <khilman@...>,
Pitre, Nicolas <npitre@...>, Zephyr Devel <
*Subject: *Re: [Zephyr-devel] MISRA

On Tue, Dec 14, 2021 at 16:42 Hibberd, Amber M <amber.m.hibberd@...>


1. As a reminder, the TSC agreed upon the Zephyr Project Coding
We are working towards compliance to the Project CG. Yes, they are a subset
of Misra, but we are not going for Misra compliance.

2. The Safety Committee, in driving toward the Project goal of
certification-ready, has partnered with Bugseng, as part of the community,
to help build momentum towards this goal.

3. There is a process for removing, revising, having exceptions, etc to
the CG rules. If you think a rule should be changed, open an issue in

The Safety Committee is bringing an update to the TSC tomorrow, where we
can have a discussion around the CG compliance work.

It’d be great to have a pre-read to frame the discussion and help us can
come prepared with questions based on said update (the linked Nov 10 email
in last week’s minutes is fairly high level).

Unfortunately, TSC agendas don’t seem to be communicated in a timely
fashion any more, usually sent out mere hours before the meeting (which is
early morning for us on the US west coast).

It makes it impossible to tell if it’s worth attending calls or not
beforehand, and I normally skip those kind of meetings to reduce meeting

I hope we can change this to be a smoother process in the future and
optimize the value of a one hour weekly meeting.



*From:* devel@... <devel@...> *On
Behalf Of *Benjamin Lindqvist
*Sent:* Monday, December 13, 2021 2:44 PM
*To:* Abramo Bagnara <abramo.bagnara@...>
*Cc:* Pitre, Nicolas <npitre@...>; Zephyr Devel <
devel@...>; Kevin Hilman <khilman@...>
*Subject:* Re: [Zephyr-devel] MISRA

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.

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.

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
this purpose.

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.

Abramo Bagnara



*Gerard Marull-Paretas*
Teslabs Engineering S.L. T. +34 622 321 312

The contents of this email message and any attachments are intended solely
for the addressee(s)
and may contain confidential and/or privileged information and may be
legally protected from
disclosure. If you are not the intended recipient of this message or their
agent, or if this message
has been addressed to you in error, please immediately alert the sender by
reply email and then
delete this message and any attachments. If you are not the intended
recipient, you are hereby
notified that any use, dissemination, copying, or storage of this message
or its attachments is
strictly prohibited.

Join to automatically receive all group messages.