Re: [XEN PATCH for 4.19] automation/eclair: add deviations agreed in MISRA meetings

[oleksii.kurochko@xxxxxxxxx]

On Wed, 2024-06-26 at 17:37 -0700, Stefano Stabellini wrote:
> On Wed, 26 Jun 2024, Federico Serafini wrote:
> > On 26/06/24 09:37, Oleksii wrote:
> > > On Tue, 2024-06-25 at 18:59 -0700, Stefano Stabellini wrote:
> > > > > +-doc_begin="The conversion from a function pointer to
> > > > > unsigned
> > > > > long or (void *) does not lose any information, provided that
> > > > > the
> > > > > target type has enough bits to store it."
> > > > > +-config=MC3R1.R11.1,casts+={safe,
> > > > > +  "from(type(canonical(__function_pointer_types)))
> > > > > +   &&to(type(canonical(builtin(unsigned
> > > > > long)||pointer(builtin(void)))))
> > > > > +   &&relation(definitely_preserves_value)"
> > > > > +}
> > > > > +-doc_end
> > > > 
> > > > This one and the ones below are the important ones! I think we
> > > > should
> > > > have them in the tree as soon as possible ideally 4.19. I ask
> > > > for
> > > > a release-ack.
> > > Just want to be sure that I understand deviations properly with
> > > this
> > > example.
> > > 
> > > If the deviation above is merged, then it would be safe from a
> > > MISRA
> > > point of view to cast a function pointer to 'unsigned long' or
> > > 'void
> > > *', and thereby MISRA won't complain about code with such
> > > conversions?
> > 
> > Exactly, taking into account section 4.7 of GCC manual.
> 
> Yes. From a Xen release perspective, it will only affect the static
> analysis jobs, making them report fewer violations. The reason why
> those specifically are important is that they are significant changes
> over the plain rule and they were already documented in rules.rst.
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>

~ Oleksii