Re: [PATCH] misra: add deviation for MISRA C Rule 11.3

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 2025-08-21 16:28, Dmytro Prokopchuk1 wrote:
> On 8/21/25 17:13, Dmytro Prokopchuk wrote:
> > On 8/21/25 12:18, Jan Beulich wrote:
> > > On 20.08.2025 09:17, Dmytro Prokopchuk1 wrote:
> > > > MISRA C Rule 11.3 states: "A cast shall not be performed between a
> > > > pointer
> > > > to object type and a pointer to a different object type."
> > > >
> > > > Violations of this rule arise due to the 'container_of' macro, which
> > > > casts
> > > > a member of a structure to its containing structure:
> > > >      container_of(ptr, type, member) ({                             
> > > > \
> > > >             typeof_field(type, member) *__mptr = (ptr);             
> > > > \
> > > >             (type *)( (char *)__mptr - offsetof(type,member) );})
> > > >
> > > > The 'container_of' macro is safe because it relies on the
> > > > standardized and
> > > > well-defined 'offsetof' macro to calculate the memory address of the
> > > > containing structure, while assuming proper alignment and ensuring 
> > > > no
> > > > undefined behavior, provided that the input pointer is valid and
> > > > points to
> > > > the specified member.
> > > >
> > > > Configure Eclair to suppress violation reports related to 
> > > > 'container_of
> > > > macro. Update 'deviations.rst' file accordingly. Add Rule 11.3 to 
> > > > the
> > > > monitored list.
> > > > No functional changes.
> > > >
> > > > Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>
> > > Looks largely okay; just one nit and a question:
> > >
> > > > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > @@ -403,6 +403,14 @@ because the semantics of the 'noreturn'
> > > > attribute do not alter the calling conve
> > > >   }
> > > >   -doc_end
> > > > +-doc_begin="Convesions in the 'container_of' macro are safe because
> > > > it relies on
> > > "Conversions" (also in deviations.rst)
> > >
> > > > --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
> > > > +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
> > > > @@ -45,6 +45,7 @@
> > > >   -enable=MC3A2.R10.2
> > > >   -enable=MC3A2.R11.1
> > > >   -enable=MC3A2.R11.2
> > > > +-enable=MC3A2.R11.3
> > > While the description mentions this change, it doesn't say why (e.g. 
> > > "no
> > > violations left" or "only this and that violation left" or some 
> > > such).
> > ARM:  813V ->   16V
> > X86: 1422V -> 1035V
> >
> > Looks OK for ARM (to be added in the monitoring list), but X86...
> > Anyway the number of reported errors has no side effect.
> >
> > Jan, decision up to you (include into monitored.ecl or not).
> >
> > Dmytro.
> Actually, better way is to remove '-enable=MC3A2.R11.3' from the
> monitored.ecl file and create separate patch (in future).
I agree

> Dmytro.
>
> > > > --- a/docs/misra/deviations.rst
> > > > +++ b/docs/misra/deviations.rst
> > > > @@ -393,6 +393,14 @@ Deviations related to MISRA C:2012 Rules:
> > > >          (i.e., less strict) alignment requirement are safe.
> > > >        - Tagged as `safe` for ECLAIR.
> > > > +   * - R11.3
> > > > +     - Convesions in the 'container_of' macro are safe because it
> > > > relies on
> > > > +       the standardized and well-defined 'offsetof' macro to
> > > > calculate the memory
> > > Actually another nit: Here as well as in the description, it would be
> > > nice
> > > to add parentheses, so indicate the function-ness of both macros 
> > > (i.e.
> > > container_of() and offsetof()).
> > >
> > > Jan
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253