Re: struct mctelem_cookie missing definition

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 16 Feb 2025, Stefano Stabellini wrote:
> On Mon, 17 Feb 2025, Jan Beulich wrote:
> > On 15.02.2025 09:59, Nicola Vetrini wrote:
> > > On 2025-02-15 00:04, Stefano Stabellini wrote:
> > >> On Fri, 14 Feb 2025, Jan Beulich wrote:
> > >>>> Would deviating macros "COOKIE2MCTE" and "MCTE2COOKIE" work?
> > >>>
> > >>> If it did, COOKIE2ID and ID2COOKIE would likely need including as 
> > >>> well.
> > >>
> > >> I wrote this patch. Nicola, can you please check the changes to
> > >> deviations.ecl, this is the first time I try to write the deviation
> > >> myself :-)
> > >>
> > >> ---
> > >> misra: add 11.2 deviation for incomplete types
> > >>
> > >> struct mctelem_cookie* is used exactly because it is an incomplete type
> > >> so the pointer cannot be dereferenced. This is deliberate. So add a
> > >> deviation for it.
> > >>
> > >> In deviations.ecl, add the list of macros that do the conversions to 
> > >> and
> > >> from struct mctelem_cookie*.
> > >>
> > >> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx>
> > >>
> > >> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
> > >> b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > >> index a28eb0ae76..87bfd2160c 100644
> > >> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > >> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > >> @@ -366,6 +366,14 @@ constant expressions are required.\""
> > >>  }
> > >>  -doc_end
> > >>
> > >> +-doc_begin="Certain pointers point to incomplete types purposely so 
> > >> that they are impossible to dereference."
> > >> +-config=MC3A2.R11.2,reports+={deliberate, 
> > >> "any_area(any_loc(any_exp(macro(^COOKIE2MCTE$))))"}
> > >> +-config=MC3A2.R11.2,reports+={deliberate, 
> > >> "any_area(any_loc(any_exp(macro(^MCTE2COOKIE$))))"}
> > >> +-config=MC3A2.R11.2,reports+={deliberate, 
> > >> "any_area(any_loc(any_exp(macro(^COOKIE2ID$))))"}
> > >> +-config=MC3A2.R11.2,reports+={deliberate, 
> > >> "any_area(any_loc(any_exp(macro(^ID2COOKIE$))))"}
> > >> +}
> > > 
> > > -config=MC3A2.R11.2,reports+={deliberate, 
> > > "any_area(any_loc(any_exp(macro(name(COOKIE2MCTE||MCTE2COOKIE||COOKIE2ID||ID2COOKIE)))))"}
> > > 
> > > Note however that there is also this deviation in place
> > > 
> > > -doc_begin="The conversion from a pointer to an incomplete type to 
> > > unsigned long does not lose any information, provided that the target 
> > > type has enough bits to store it."
> > > -config=MC3A2.R11.2,casts+={safe,
> > >    "from(type(any()))
> > >     &&to(type(canonical(builtin(unsigned long))))
> > >     &&relation(definitely_preserves_value)"
> > > }
> > > -doc_end
> > > 
> > > I was a bit confused by Jan's remark, which seemed correct, but I 
> > > couldn't see any violations in the report, so I dug a bit deeper. 
> > > ID2COOKIE and COOKIE2ID, which operate to/from unsigned long are already 
> > > excluded due to being safe. If you envision those macros to be used with 
> > > other types, then your deviation should mention them, otherwise they are 
> > > already handled.
> > 
> > Yet then can't we leverage that deviation to also make the other two
> > covered:
> > 
> > #define     COOKIE2MCTE(c)          ((struct mctelem_ent *)(unsigned 
> > long)(c))
> > #define     MCTE2COOKIE(tep)        ((mctelem_cookie_t)(unsigned long)(tep))
> > 
> > Arguable that's ...
> 
> Jan is asking why ID2COOKIE and COOKIE2ID are considered safe, while
> COOKIE2MCTE and MCTE2COOKIE are not. I think the reason is that
> ID2COOKIE and COOKIE2ID convert to/from unsigned long and that falls
> under the other deviation we already have:
> 
> -doc_begin="The conversion from a pointer to an incomplete type to 
> unsigned long does not lose any information, provided that the target 
> type has enough bits to store it."
> -config=MC3A2.R11.2,casts+={safe,
>    "from(type(any()))
>     &&to(type(canonical(builtin(unsigned long))))
>     &&relation(definitely_preserves_value)"
> 
> On the other hand COOKIE2MCTE and MCTE2COOKIE convert to/from another
> pointer type, so they don't fall under the same deviation.


To expand on this, I believe the deviation was specifically intended for
conversions leading to integers, rather than pointers that could
potentially have alignment issues. This is why the original deviation
made sense, and expanding its scope to include COOKIE2MCTE and
MCTE2COOKIE may not be feasible.