On 13.02.2025 15:52, Nicola Vetrini wrote:
> On 2025-02-13 15:22, Jan Beulich wrote:
>> Any (signed) integer is okay to pass into radix_tree_int_to_ptr(), yet
>> left shifting negative values is UB. Use an unsigned intermediate type,
>> reducing the impact to implementation defined behavior (for the
>> unsigned->signed conversion).
>>
>> Also please Misra C:2012 rule 7.3 by dropping the lower case numeric
>> 'l'
>> tag.
>>
>> No difference in generated code, at least on x86.
>>
>> Fixes: b004883e29bb ("Simplify and build-fix (for some gcc versions)
>> radix_tree_int_to_ptr()")
>> Reported-by: Teddy Astie <teddy.as...@vates.tech>
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>> ---
>> Bugseng: Why was the 7.3 violation not spotted by Eclair? According to
>> tagging.ecl the codebase is clean for this rule, aiui.
>>
>
> radix-tree.{c,h} is out of scope:
>
> automation/eclair_analysis/ECLAIR/out_of_scope.ecl:32:-file_tag+={out_of_scope,"^xen/include/xen/radix-tree\\.h$"}
> docs/misra/exclude-list.json:153: "rel_path":
> "common/radix-tree.c",
Is there a record of why they are excluded? Is it further explainable
why exclude-list.json mentions only the .c file and out_of_scope.ecl
mentions only the .h one? Shouldn't different parts be in sync?
> We are in the process of setting up a wider analysis (i.e. with a
> different exclusion set) with a broader configuration that may catch
> these issues.
Good.
Jan
