Re: [XEN PATCH][for-4.19 v3] xen: address violations of Rule 11.9

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.10.2023 02:54, Stefano Stabellini wrote:
> On Thu, 19 Oct 2023, andrew.cooper3@xxxxxxxxxx wrote:
>> On 18/10/2023 2:42 pm, Nicola Vetrini wrote:
>>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>>> index ee7aed0609d2..1b00e4e3e9b7 100644
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -199,6 +199,11 @@ Deviations related to MISRA C:2012 Rules:
>>>         See automation/eclair_analysis/deviations.ecl for the full 
>>> explanation.
>>>       - Tagged as `safe` for ECLAIR.
>>>  
>>> +   * - R11.9
>>> +     - __ACCESS_ONCE uses a 0 as a null pointer constant to check if a 
>>> type is
>>> +       scalar, therefore its usage for this purpose is allowed.
>>
>> This is still deeply misleading.
>>
>> There is an integer, which happens to be 0 but could be anything, used
>> for a compile time typecheck[1].  In some cases this may be interpreted
>> as a pointer constant, and is permitted for this purpose.
>>
>> ~Andrew
>>
>> [1] I know I wrote scalar typecheck in the comment, but I suspect that
>> what I actually meant was non-compound-type typecheck.
> 
> To help Nicola find the right wording do you have a concrete suggestion
> for the text to use?
> 
> Reading your reply, I am guessing it would be:
> 
> * - R11.9
>   - __ACCESS_ONCE uses an integer, which happens to be zero, as a
>     non-compound-type typecheck. The typecheck uses a cast. The usage of
>     zero or other integers for this purpose is allowed.

"non-compound" isn't correct either: __int128_t, for example, isn't a
compound type but may not be used with ACCESS_ONCE(). Furthermore
certain compound types are, as indicated earlier, in principle okay
to use with ACCESS_ONCE(). Both are shortcomings of the present
implementation, which imo shouldn't propagate into this document. I'd
say just "as a compile time check".

Jan