On 22/06/24 14:22, Andrew Cooper wrote:
On 22/06/2024 11:48 am, Federico Serafini wrote:
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index e2653f77eb..6bdfe7c883 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -328,6 +328,16 @@ of the short-circuit evaluation strategy of such logical
operators."
-config=MC3R1.R13.5,reports+={disapplied,"any()"}
-doc_end
+-doc_begin="Macros alternative_v?call[0-9] use sizeof and typeof to check that th argument types match the corresponding parameter ones."
Typo "th" => "the". Can be fixed on commit.
+-config=MC3R1.R13.6,reports+={deliberate,"any_area(any_loc(any_exp(macro(^alternative_vcall[0-9]$))&&file(^xen/arch/x86.*$)))"}
+-config=B.UNEVALEFF,reports+={deliberate,"any_area(any_loc(any_exp(macro(^alternative_v?call[0-9]$))&&file(^xen/arch/x86.*$)))"}
There will be expansions of these macros outside of arch/x86/.
drivers/iommu/ as an example.
Is the file() clause targetting the source of the macro (in which it
probably wants making more specific to alternative_call.h), or the
expansions of the macro (in which case it probably wants dropping
entirely) ?
It is targetting the source of the macro,
we can make it more specific.
+-doc_end
+
+-doc_begin="Macro chk_fld is only used to introduce BUILD_BUG_ON checks in
very specific cases where the usage is correct and can be checked by code inspection.
+The BUILD_BUG_ON checks check that EFI_TIME and struct xenpf_efi_time fields
match."
+-config=MC3R1.R13.6,reports+={deliberate,"any_area(any_loc(any_exp(macro(^chk_fld$))&&file(^xen/common/efi/runtime\\.c$)))"}
+-doc_end
It's just occurred to me. Anything, no matter how complicated, inside a
BUILD_BUG_ON() is clearly a compile time thing so has no relevant side
effects.
Is it possible to generally exclude any sizeof/alignof/typeof inside a
BUILD_BUG_ON()? That would be better than identifying every user locally.
Sure.
I will send a v2 with your observations.
--
Federico Serafini, M.Sc.
Software Engineer, BUGSENG (http://bugseng.com)
