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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]

On Fri, Jun 26, 2026 at 08:28:34PM +0200, Quentin Schulz wrote:
> 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@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@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);
> 
> ?

I wish it was easier to test questions like that.

> 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.

Looking at open issues on test/lib/lmb.c, which has a "ut_assert(ret >= 0)"
in it, and is happy with it, yes, we should be able to make changes as
you suggest I believe.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]