On 04.09.2025 16:50, scan-ad...@coverity.com wrote:
> Hi,
>
> Please find the latest report on new defect(s) introduced to XenProject found
> with Coverity Scan.
>
> 1 new defect(s) introduced to XenProject found with Coverity Scan.
> 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the
> recent build analyzed by Coverity Scan.
>
> New defect(s) Reported-by: Coverity Scan
> Showing 1 of 1 defect(s)
>
>
> ** CID 1665214: Integer handling issues (INTEGER_OVERFLOW)
> /tools/firmware/xen-dir/xen-root/xen/common/symbols.c: 123 in
> symbols_lookup()
>
>
> _____________________________________________________________________________________________
> *** CID 1665214: Integer handling issues (INTEGER_OVERFLOW)
> /tools/firmware/xen-dir/xen-root/xen/common/symbols.c: 123 in
> symbols_lookup()
> 117 }
> 118
> 119 /* If we hit an END symbol, move to the previous (real) one. */
> 120 if (!symbols_names[get_symbol_offset(low)]) {
> 121 ASSERT(low);
With this I wonder ...
> 122 symbol_end = symbols_address(low);
>>>> CID 1665214: Integer handling issues (INTEGER_OVERFLOW)
>>>> Expression "--low", where "low" is known to be equal to 0, underflows
>>>> the type of "--low", which is type "unsigned int".
> 123 --low;
... how "low" can be known to be zero when getting here. Without the
assertion I would accept that the tool doesn't understand that an
"end" symbol can't come first (albeit imo the report then would still
be a false positive one).
Jan
