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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.08.2023 12:01, Nicola Vetrini wrote:
> 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.

Correct. The goal wants to be to allow for such future changes in as
seamless a manner as possible. By tweaking the script generating
these struct fields, we can eliminate the present instance and avoid
any future instances showing up, and we also won't need to remember
to add SAF-* comments at any point in time.

Jan