On Sat, Dec 11, 2021 at 2:01 PM Nicolas Pitre <npitre@...> wrote:

<rant mode on>

Could someone tell me what is all this MISRA compliance eagerness for?
I can't believe that no one rebelled against that yet.

I started to question a bunch of the choices in the early PRs, but it was moot.

I also got the impression that the mess they are creating now with the
enormous amount of obfuscating casting can/should be fixed once
they've worked through the bulk of the warnings and can scale back
some of them.

I _really_ hope that to be the case, and not a "well, the coding is
done now, so please merge it into main as well". I worry that'll be a
bad experience for everybody.

I just looked at a proposed PR and this makes me want to cry.

Some of the changes are good, like stricter boolean usage.

But the majority of the changes are pure code obfuscation!

Who in its right mind will believe that sprinkling typecasts around
would make the code any safer and understandable? And that's not
mentioning those _double_ typecasts being added too!!! We should instead
aim for cast _reduction_ to let the compiler warn more about type
mismatches and air the code, not add new ones!

I fully agree. Once they can complete the first pass on their topic
branch, I expect there to be a checkpoint with a judgment call on
whether it's a net improvement to Zephyr or not, and what to do with
it w.r.t. merging piece of it into the main development branches.

For now, I am willing to give them the benefit of the doubt, but I do
worry about the final outcome being a project that's significantly
harder to work with and understand. But I will wait until they're
ready for said scruity.


[...]

So I really do challenge if MISRA compliance is a good thing for the
project. Some of it certainly makes sense. Some of it is really
questionable and should be excluded.

I do guess (even if I don't understand why in the end) that some Zephyr
users do require MISRA compliance for their project. I however do
believe that this is not beneficial for the Zephyr community as a whole,
and that the cost of MISRA compliance and its side effects should not be
imposed on everyone without further scrutiny and discrimination.

Again, 100% agree, especially if we start to approach things with
"every PR needs to have clean MISRA checks". I certainly worry about
the overall readability and general ease of both using
(reading/understanding) as well as contributing to the project.

But, as I said above, I'm willing to have them do the work and then we
see how things look like when it's ready.

Static analysis tools have come a long way and they are far more useful,
realistic and relevant when it comes to code validity and correctness at
this point.

My understanding is that MISRA and correctness are two completely
unrelated concepts, and MISRA is mostly about avoiding undefined
behaviors in specifications (that might not be causing bugs).

That, plus business motivations of having a code base that is passing
all checks -- ("Our code is MISRA clean", and whatever that might do
to product malfunction liabilities or other certifications, etc.).

Many embedded libraries and SDK's out there already maintain a MISRA
compliance exception list. I think this would be a sane thing to do and
that wouldn't be a first.

What would you expect that to look like? Specific rules in MISRA that
we're choosing to not conform to? I think that could be a very useful
discussion to have once we see how the final outcome looks like, and
avoid the most obfuscating ones if we can.


-Olof