Hi Tom,
On 6/23/26 12:43 AM, Tom Rini wrote:
Hey all,
Coverity is back up finally and so here's the result of changes for the
last three RCs.
---------- Forwarded message ---------
From: <[email protected]>
Date: Mon, Jun 22, 2026 at 4:40 PM
Subject: New Defects reported by Coverity Scan for Das U-Boot
To: <[email protected]>
Hi,
Please find the latest report on new defect(s) introduced to *Das U-Boot*
found with Coverity Scan.
- *New Defects Found:* 1
- 4 defect(s), reported by Coverity Scan earlier, were marked fixed in
the recent build analyzed by Coverity Scan.
- *Defects Shown:* Showing 1 of 1 defect(s)
Defect Details
** CID 646439: Integer handling issues (INTEGER_OVERFLOW)
/test/cmd/part.c: 53 in setup_gpt_partitions()
_____________________________________________________________________________________________
*** CID 646439: Integer handling issues (INTEGER_OVERFLOW)
/test/cmd/part.c: 53 in setup_gpt_partitions()
47 snprintf(dev_str, sizeof(dev_str), "%u", mmc_dev_num);
48
49 ret = blk_get_device_by_str("mmc", dev_str, &mmc_dev_desc);
50 if (ret == -ENODEV)
51 return -EAGAIN;
52
CID 646439: Integer handling issues (INTEGER_OVERFLOW)
Expression "_val2", where "ret" is known to be equal to -22, overflows the type of
"_val2", which is type "unsigned int".
53 ut_asserteq(mmc_dev_num, ret);
54
Does Coverity complain if we do:
ut_assert(ret >= 0);
ut_asserteq(mmc_dev_num, ret);
?
We also use the same ut_asserteq() check in many oher places with the
return value of blk_get_device_by_str() so I'm surprised it doesn't
complain about those and why.
Cheers,
Quentin
