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

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

On 19/10/2023 09:03, Jan Beulich wrote:
> On 19.10.2023 02:54, Stefano Stabellini wrote:
>> On Thu, 19 Oct 2023, andrew.cooper3@citrix.com 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

Ok, I'll amend it

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