[PATCH] misra: add deviation for MISRA C Rule 18.3

[PATCH] misra: add deviation for MISRA C Rule 18.3

[Dmytro Prokopchuk1]

MISRA C Rule 18.3 states:"The relational operators >, >=, < and <= shall
not be applied to objects of pointer type except where they point into
the same object."

Comparisons in the 'find_text_region()' function are safe because linker
symbols '_stext' and '_etext' represent fixed virtual addresses within
the same '.text' region, and the function 'addr' argument is explicitly
compared to known valid memory bounds ('text_start' and 'text_end')
derived from these linker symbols:
    if ( (void *)addr >= iter->text_start &&
         (void *)addr <  iter->text_end )

Configure Eclair to suppress violation reports occured in the function
'find_text_region()'. Update 'deviations.rst' file accordingly.
No functional changes.

Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
---
Test CI pipeline:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1993673043
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
 docs/misra/deviations.rst                        | 8 ++++++++
 2 files changed, 14 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 7f3fd35a33..32b596c9da 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -590,6 +590,12 @@ C99 Undefined Behaviour 45: Pointers that do not point into, or just beyond, the
 -config=MC3A2.R18.2,reports+={safe, "any_area(any_loc(any_exp(macro(^page_to_mfn$))))"}
 -doc_end
 
+-doc_begin="Comparisons in the 'find_text_region()' function are safe because linker symbols '_stext' and '_etext' represent fixed
+virtual addresses within the same '.text' region, and the function 'addr' argument is explicitly compared to known valid memory
+bounds ('text_start' and 'text_end') derived from these linker symbols."
+-config=MC3A2.R18.3,reports+={safe, "any_area(any_loc(file(^xen/common/virtual_region\\.c$))&&context(name(find_text_region)))"}
+-doc_end
+
 -doc_begin="Flexible array members are deliberately used and XEN developers are aware of the dangers related to them:
 unexpected result when the structure is given as argument to a sizeof() operator and the truncation in assignment between structures."
 -config=MC3A2.R18.7,reports+={deliberate, "any()"}
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 2119066531..a726fb22a8 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -586,6 +586,14 @@ Deviations related to MISRA C:2012 Rules:
        are safe.
      - Tagged as `safe` for ECLAIR.
 
+   * - R18.3
+     - Comparisons in the 'find_text_region()' function are safe because
+       linker symbols '_stext' and '_etext' represent fixed virtual
+       addresses within the same '.text' region, and the function 'addr'
+       argument is explicitly compared to known valid memory bounds
+       ('text_start' and 'text_end') derived from these linker symbols.
+     - Tagged as `safe` for ECLAIR.
+
    * - R20.4
      - The override of the keyword \"inline\" in xen/compiler.h is present so
        that section contents checks pass when the compiler chooses not to
-- 
2.43.0

Re: [PATCH] misra: add deviation for MISRA C Rule 18.3

[Nicola Vetrini]

On 2025-08-20 14:44, Dmytro Prokopchuk1 wrote:
> MISRA C Rule 18.3 states:"The relational operators >, >=, < and <= 
> shall
> not be applied to objects of pointer type except where they point into
> the same object."
> 
> Comparisons in the 'find_text_region()' function are safe because 
> linker
> symbols '_stext' and '_etext' represent fixed virtual addresses within
> the same '.text' region, and the function 'addr' argument is explicitly
> compared to known valid memory bounds ('text_start' and 'text_end')
> derived from these linker symbols:
>     if ( (void *)addr >= iter->text_start &&
>          (void *)addr <  iter->text_end )
> 
> Configure Eclair to suppress violation reports occured in the function
> 'find_text_region()'. Update 'deviations.rst' file accordingly.
> No functional changes.
> 
> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

with two NITs below:

> ---
> Test CI pipeline:
> https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1993673043
> ---
>  automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
>  docs/misra/deviations.rst                        | 8 ++++++++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
> b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 7f3fd35a33..32b596c9da 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -590,6 +590,12 @@ C99 Undefined Behaviour 45: Pointers that do not 
> point into, or just beyond, the
>  -config=MC3A2.R18.2,reports+={safe, 
> "any_area(any_loc(any_exp(macro(^page_to_mfn$))))"}
>  -doc_end
> 
> +-doc_begin="Comparisons in the 'find_text_region()' function are safe 
> because linker symbols '_stext' and '_etext' represent fixed
> +virtual addresses within the same '.text' region, and the function 
> 'addr' argument is explicitly compared to known valid memory
> +bounds ('text_start' and 'text_end') derived from these linker 
> symbols."

Maybe ['text_start', 'text_end') here and below to emphasize that this 
is a range?

> +-config=MC3A2.R18.3,reports+={safe, 
> "any_area(any_loc(file(^xen/common/virtual_region\\.c$))&&context(name(find_text_region)))"}
> +-doc_end
> +
>  -doc_begin="Flexible array members are deliberately used and XEN 
> developers are aware of the dangers related to them:
>  unexpected result when the structure is given as argument to a 
> sizeof() operator and the truncation in assignment between structures."
>  -config=MC3A2.R18.7,reports+={deliberate, "any()"}
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index 2119066531..a726fb22a8 100644
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -586,6 +586,14 @@ Deviations related to MISRA C:2012 Rules:
>         are safe.
>       - Tagged as `safe` for ECLAIR.
> 
> +   * - R18.3
> +     - Comparisons in the 'find_text_region()' function are safe 
> because
> +       linker symbols '_stext' and '_etext' represent fixed virtual
> +       addresses within the same '.text' region, and the function 
> 'addr'

s/function 'addr' argument/function parameter 'addr'/

> +       argument is explicitly compared to known valid memory bounds
> +       ('text_start' and 'text_end') derived from these linker 
> symbols.
> +     - Tagged as `safe` for ECLAIR.
> +
>     * - R20.4
>       - The override of the keyword \"inline\" in xen/compiler.h is 
> present so
>         that section contents checks pass when the compiler chooses not 
> to

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

Re: [PATCH] misra: add deviation for MISRA C Rule 18.3

[Jan Beulich]

On 20.08.2025 14:44, Dmytro Prokopchuk1 wrote:
> MISRA C Rule 18.3 states:"The relational operators >, >=, < and <= shall
> not be applied to objects of pointer type except where they point into
> the same object."
> 
> Comparisons in the 'find_text_region()' function are safe because linker
> symbols '_stext' and '_etext' represent fixed virtual addresses within

All symbols, after linking, "represent fixed virtual addresses". Not sure
what you're actually meaning to get across here.

> the same '.text' region, and the function 'addr' argument is explicitly
> compared to known valid memory bounds ('text_start' and 'text_end')
> derived from these linker symbols:
>     if ( (void *)addr >= iter->text_start &&
>          (void *)addr <  iter->text_end )

Overall I don't think the deviation can be justified this way. Or else
the same could be said about other similar checks, which may not be
valid to deviate. One particularly important aspect that imo needs
discussing is the safety of the logic with code transformations in mind
that a compiler may in principle do (leveraging UB for optimization
purposes).

Jan