Re: [XEN PATCH v2] x86/cpu-policy: justify a violation of MISRA C:2012 Rule 1.3

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 02/08/2023 11:47, Jan Beulich wrote:
> On 02.08.2023 10:57, Nicola Vetrini wrote:
> > The empty feature set 'str_7c1' in 'tools/misc/xen-cpuid.c' causes the
> > struct declaration to have no named members, hence violating
> > Rule 1.3:
> > "There shall be no occurrence of undefined or critical unspecified 
> > behaviour"
> > because it is forbidden by ISO/IEC 9899:1999(E), Section 6.7.2.1.7:
> > "If the struct-declaration-list contains no named
> > members, the behavior is undefined."
> >
> > Given that Xen is using an undocumented GCC extension that specifies 
> > the
> > behaviour upon defining a struct with no named member, this construct 
> > is
> > well-defined and thus it is marked as safe.
> Especially after realizing that I was wrong here (I was under the wrong
> impression that we'd generate a struct without members, when it's one
> without named members, yet [to me at least] only the former is a known
> gcc extension we use), I've sent an alternative proposal. Let's see
> whether in particular Andrew considers this acceptable.
Well, I don't know the exact discussion on this in that MISRA meeting 
(25/07 iirc),
but the outcome I'm aware of was to deviate that construct because there 
are possibly
others like that in other configurations/future patches. Anyway, this 
usage does not
fall under gcc's documented extensions (either the one you mentioned or 
the one about
unnamed fields, 6.63), but it does allow it (has a warning only on 
-pedantic afaict),
hence why I put undocumented here.

In the meantime, I can test your patch to see if it has no unintended 
impact on other code
w.r.t. Rule 1.3.

Regards,

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)