Re: [PATCH v1] misra: add deviation of Rule 10.1 for unary minus

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

On 2025-04-23 22:48, Julien Grall wrote:
> Hi Victor,
> 
> On 23/04/2025 18:54, victorm.lira@amd.com wrote:
>> From: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> 
>> MISRA C Rule 10.1 states:
>> "Operands shall not be of an inappropriate essential type"
>> 
>> The unary minus operator applied to an unsigned quantity has
>> a semantics (wrap around) that is well-known to all Xen developers.
>> Thus, this operation is deemed safe.
>> 
>> No functional change.
>> 
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
>> Signed-off-by: Victor Lira <victorm.lira@amd.com>
>> ---
>> Changes v1:
>> - add rule title to commit message
>> ---
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>> Cc: Anthony PERARD <anthony.perard@vates.tech>
>> Cc: Michal Orzel <michal.orzel@amd.com>
>> Cc: Jan Beulich <jbeulich@suse.com>
>> Cc: Julien Grall <julien@xen.org>
>> Cc: Roger Pau Monné <roger.pau@citrix.com>
>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>> Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> Cc: Federico Serafini <federico.serafini@bugseng.com>
>> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
>> ---
>>   automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
>>   docs/misra/deviations.rst                        | 6 ++++++
>>   2 files changed, 12 insertions(+)
>> 
>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> index 303b06203a..2cfce850bd 100644
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -347,6 +347,12 @@ constant expressions are required.\""
>>     "any()"}
>>   -doc_end
>> 
>> +-doc_begin="Unary minus operations on non-negative integers have a 
>> semantics (wrap around) that is well-known to all Xen developers."
>> +-config=MC3A2.R10.1,etypes+={safe,
>> +  "stmt(node(unary_operator)&&operator(minus))",
>> +  "src_expr(definitely_in(0..))"}
>> +-doc_end
>> +
>>   #
>>   # Series 11
>>   #
>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>> index cfdd1a9838..c5897e31c5 100644
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -321,6 +321,12 @@ Deviations related to MISRA C:2012 Rules:
>>          If no bits are set, 0 is returned.
>>        - Tagged as `safe` for ECLAIR.
>> 
>> +   * - R10.1
>> +     - Applying the unary minus operator to an unsigned quantity has 
>> a
>> +       semantics (wrap around) that is well-known to all Xen 
>> developers.
>> +       For this reason, the operation is safe.
> 
> I have realized we use similar wording in the rest of the deviations, 
> but this is rather fragile argument. "well-known" is very subjective 
> and could change over time.
> 
> How many violations do we have? Could we deviate them one by one?
> 

Hi Julien,

around 10 on ARM, but more than 100 on x86 scattered around multiple 
constructs (e.g. not only inside a handful of macros), so I don't think 
it's feasible to deviate them one by one. I do agree that the wording is 
subjective, but it is rather well-defined which toolchains and 
architectures are used (C-language-toolchain.rst). Perhaps a wording 
mentioning the specific assumptions implied here can address your 
concerns?

Thanks,
  Nicola

> Cheers,

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253