Fwd: New Defects reported by Coverity Scan for Das U-Boot

[Quentin Schulz]

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: <scan-admin at coverity.com>
> Date: Mon, Jun 22, 2026 at 4:40 PM
> Subject: New Defects reported by Coverity Scan for Das U-Boot
> To: <tom.rini at gmail.com>
> 
> 
> 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