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

[andrew.cooper3@xxxxxxxxxx]

On 19/10/2023 1:54 am, 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.
>
> Andrew, please confirm? Nicola, please also confirm that this version of
> the text would be suitable for an assessor.

Yes, that paragraph was intended as a specific suggestion, but I see I
did miss __ACCESS_ONCE() off the start.  Sorry.

And yes - we should probably just leave it as "a compile time
typecheck".  Anything more specific isn't relevant here, and isn't
trivial to describe either.

~Andrew