Re: [PATCH 0/9] MISRA C 2012 8.1 rule fixes

[Roberto Bagnara <roberto.bagnara@xxxxxxxxxxx>]

Hi there.

Rule 8.1 only applies to C90 code, as all the violating instances are
syntax errors in C99 and later versions of the language.  So,
the following line does not contain a violation of Rule 8.1:

    unsigned x;

It does contain a violation of Directive 4.6, though, whose correct
handling depends on the intention (uint32_t, uin64_t, size_t, ...).

As a side note (still on the theme of the many ways of referring
to a concrete type) Rule 6.1 says not to use plain int for a bitfield
and using an explicitly signed or unsigned type instead.
(Note that Directive 4.6 does not apply to bitfield types.)
So

    int field1:2;

is not compliant; the following are compliant:

    signed int   field1:2;
    unsigned int field2:3;

But also the following are compliant, and we much favor
this variant as the specification of "int" buys nothing
and can even mislead someone into thinking that more bits
are reserved:

    signed   field1:2;
    unsigned field2:3;

I mention this to encourage, as a matter of style, not to add
"int" on bitfield types currently specified as "signed" or "unsigned".
Kind regards,

   Roberto

On 22/06/22 21:23, Stefano Stabellini wrote:
> +Roberto
>
>
> Hi Roberto,
>
> A quick question about Rule 8.1.
>
>
> Michal sent a patch series to fix Xen against Rule 8.1 (here is a link
> if you are interested: https://marc.info/?l=xen-devel&m=165570851227125)
>
> Although we all generally agree that the changes are a good thing, there
> was a question about the rule itself. Specifically, is the following
> actually a violation?
>
>    unsigned x;
>
>
> Looking through the examples in the MISRA document I can see various
> instances of more confusing and obvious violations such as:
>
>    const x;
>    extern x;
>
> but no examples of using "unsigned" without "int". Do you know if it is
> considered a violation?
>
>
> Thanks!
>
> Cheers,
>
> Stefano
>
>
>
> On Wed, 22 Jun 2022, Jan Beulich wrote:
> > > > > > > On 22.06.2022 12:25, Jan Beulich wrote:
> > > > > > > > On 20.06.2022 09:02, Michal Orzel wrote:
> > > > > > > > > This series fixes all the findings for MISRA C 2012 8.1 rule, reported by
> > > > > > > > > cppcheck 2.7 with misra addon, for Arm (arm32/arm64 - target allyesconfig).
> > > > > > > > > Fixing this rule comes down to replacing implicit 'unsigned' with explicit
> > > > > > > > > 'unsigned int' type as there are no other violations being part of that rule
> > > > > > > > > in the Xen codebase.
> > > > > > > > I'm puzzled, I have to admit. While I agree with all the examples in the
> > > > > > > > doc, I notice that there's no instance of "signed" or "unsigned" there.
> > > > > > > > Which matches my understanding that "unsigned" and "signed" on their own
> > > > > > > > (just like "long") are proper types, and hence the omission of "int"
> > > > > > > > there is not an "omission of an explicit type".
> [...]
>
> > > > > > Neither the name of the variable nor the comment clarify that this is about
> > > > > > the specific case of "unsigned". As said there's also the fact that they
> > > > > > don't appear to point out the lack of "int" when seeing plain "long" (or
> > > > > > "long long"). I fully agree that "extern x;" or "const y;" lack explicit
> > > > > > "int".