On Wed, 15 Dec 2021, Abramo Bagnara wrote:

Il 15/12/21 19:50, Nicolas Pitre ha scritto:

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.

Are you really arguing that a commented explicit cast (for non obviously
value-preserving conversion) is worse than an implicit cast?

Absolutely! This is a great example of papering over what is most likely
a flaw in the code. Instead of questioning the fundamental of such
non-preserving conversion, the added cast gives the impression that the
code is legitimate while it most likely isn't. If there is a scanning
tool that spots those occurrences then great. But making them invisible
to the tool with typecasts is worse than doing nothing about it.

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.

Are you taking in account that although you can write tests for compiler
*extensions* (defining otherwise undefined behaviors), you definitely can not
write tests for compiler undefined and unspecified behaviors?

Extensions if you wish, although I can't find any extension in the gcc
manual that documents arithmetic operations on NULL pointers for
example, or more precisely typed pointers that may happen to test as
NULL. Yet this can easily be tested.

Incidentally, most dubious and truly undefined compiler behaviors tend
to exhibit themselves ... with the use of typecasts.

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
though.

IMHO you are victim of an huge misunderstanding: the aim is *only*
better code quality and conformance is exclusively a mean to achieve
that.

Maybe *you* get it, but I'm under the impression that this is not fully
understood by some people/corporations that make it an acceptance
requirement. Therefore that paragraph of mine above was aimed at them.

When a specific instance of conformance to whatever rule hurts code quality it
should never been done, who says otherwise prove it does not know XYZ
(supposing it is a sane coding standard, like MISRA is).

Amen !

If you are able to present a single non-deviable MISRA rule that hurts code
quality and has been chosen for Zephyr community please present it, otherwise
we risk to talk about gut feelings.

I did. Twice and a half so far.

I'm not invested in the MISRA spec though, so pardon me if I didn't
discriminate on deviablility.

Similarily if you are able to present a single deviable MISRA rule that in
*any* instance hurts code quality/verificability/readability/understanding
and/or has no point to exists please talk about that under a pure technical
point of view.

Hopefully my arguments were technical enough.

In summary, I believe that to keep repeating "XYZ conformance stinks" does not
help.

It stinks when those things become political for commercial or similar
reasons. Personally I'm only interested in a technical debate.


Nicolas