misra: add deviation of Rule 10.1 for unary minus

MISRA C Rule 10.1 states:
"Operands shall not be of an inappropriate essential type"

The unary minus operator applied to an unsigned type(s) has
a semantics (wrap around) that is well-defined by the toolchains.
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>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>

automation/eclair_analysis/ECLAIR/deviations.ecl

@@ -342,6 +342,12 @@ constant expressions are required.\""
   "any()"}
 -doc_end
 
+-doc_begin="Unary minus operations on unsigned type(s) have a semantics (wrap around) that is well-defined by the toolchains."
+-config=MC3A2.R10.1,etypes+={safe,
+  "stmt(node(unary_operator)&&operator(minus))",
+  "src_expr(definitely_in(0..))"}
+-doc_end
+
 #
 # Series 11
 #

docs/misra/deviations.rst

@@ -325,6 +325,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 unsigned type(s) has a
+       semantics (wrap around) that is well-defined by the toolchains.
+       For this reason, the operation is safe.
+     - Tagged as `safe` for ECLAIR.
+
    * - R11.1
      - The conversion from a function pointer to unsigned long or (void \*) does
        not lose any information, provided that the target type has enough bits