Re: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.09.2025 14:45, Dmytro Prokopchuk1 wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -98,6 +98,23 @@ Deviations related to MISRA C:2012 Rules:
>         even when debug-only assertions like `ASSERT_UNREACHABLE()` are 
> removed.
>       - ECLAIR has been configured to ignore those statements.
>  
> +   * - R2.1
> +     - In the specific build configuration (when the config CONFIG_ACPI is 
> not
> +       defined) the 'BUG()' macro is intentionally used in the 
> 'prepare_acpi()'
> +       function in the header file 'xen/arch/arm/include/asm/domain_build.h'
> +       defined as 'static inline' to trigger a runtime error if ACPI-related
> +       features are used incorrectly.
> +     - Tagged as `deliberate` for ECLAIR.

I response to me outlining a deviation-less alternative you tried it out
and said it works. Then why is the deviation still being put in place?

> +   * - R2.1
> +     - In the specific build configuration (when the config CONFIG_HAS_ITS 
> is not
> +       defined) the 'BUG()' macro is intentionally used in the 
> 'gicv3_do_LPI()'
> +       and 'gicv3_its_setup_collection()' functions defined as 'static 
> inline'
> +       in the header file 'xen/arch/arm/include/asm/gic_v3_its.h' to catch 
> and
> +       prevent any unintended execution of code that should only run when 
> ITS is
> +       available.
> +     - Tagged as `deliberate` for ECLAIR.

Taking both together and considering that really, when we no longer limit
Misra checking to specific configurations, we are going to have many more
of such "problems", I fear this way of deviating them simply doesn't scale.
Imo this needs a SAF-style deviation that can be applied without needing to
add a new section of text every time.

Jan