[PATCH] test: cmd: part: fix integer handling in setup_gpt_partitions()

[PATCH] test: cmd: part: fix integer handling in setup_gpt_partitions()

[Dario Binacchi]

Coverity reports an INTEGER_OVERFLOW issue because ut_asserteq() compares
an unsigned int (mmc_dev_num) with ret, which can hold a negative error
code.

Addresses-Coverity-ID: CID 646439: Integer handling issues  (INTEGER_OVERFLOW)
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>

---

 test/cmd/part.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/cmd/part.c b/test/cmd/part.c
index e0149011476c..b01bc286723b 100644
--- a/test/cmd/part.c
+++ b/test/cmd/part.c
@@ -50,7 +50,7 @@ static int setup_gpt_partitions(struct unit_test_state *uts,
 	if (ret == -ENODEV)
 		return -EAGAIN;
 
-	ut_asserteq(mmc_dev_num, ret);
+	ut_assert(ret >= 0 && ret == mmc_dev_num);
 
 	if (CONFIG_IS_ENABLED(RANDOM_UUID)) {
 		for (i = 0; i < ARRAY_SIZE(gpt_parts); i++)
-- 
2.43.0

base-commit: 6902fb4c17faa375003124c451c2550deab5463d
branch: test_cmd_part

Re: [PATCH] test: cmd: part: fix integer handling in setup_gpt_partitions()

[Quentin Schulz]

Hi Dario,

On 6/26/26 8:33 PM, Dario Binacchi wrote:
> Coverity reports an INTEGER_OVERFLOW issue because ut_asserteq() compares
> an unsigned int (mmc_dev_num) with ret, which can hold a negative error
> code.
> 

The trick here is that ut_asserteq() takes two arguments and casts both 
as unsigned int, hence why it complains.

If Coverity is happy, I'm happy :)

This looks fine to me, so:

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [PATCH] test: cmd: part: fix integer handling in setup_gpt_partitions()

[Tom Rini]

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

On Fri, Jun 26, 2026 at 08:40:36PM +0200, Quentin Schulz wrote:
> Hi Dario,
> 
> On 6/26/26 8:33 PM, Dario Binacchi wrote:
> > Coverity reports an INTEGER_OVERFLOW issue because ut_asserteq() compares
> > an unsigned int (mmc_dev_num) with ret, which can hold a negative error
> > code.
> > 
> 
> The trick here is that ut_asserteq() takes two arguments and casts both as
> unsigned int, hence why it complains.
> 
> If Coverity is happy, I'm happy :)
> 
> This looks fine to me, so:
> 
> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Yes, were you able to push this through coverity on your own?

-- 
Tom

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

Re: [PATCH] test: cmd: part: fix integer handling in setup_gpt_partitions()

[Dario Binacchi]

On Fri, Jun 26, 2026 at 11:58 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Jun 26, 2026 at 08:40:36PM +0200, Quentin Schulz wrote:
> > Hi Dario,
> >
> > On 6/26/26 8:33 PM, Dario Binacchi wrote:
> > > Coverity reports an INTEGER_OVERFLOW issue because ut_asserteq() compares
> > > an unsigned int (mmc_dev_num) with ret, which can hold a negative error
> > > code.
> > >
> >
> > The trick here is that ut_asserteq() takes two arguments and casts both as
> > unsigned int, hence why it complains.
> >
> > If Coverity is happy, I'm happy :)
> >
> > This looks fine to me, so:
> >
> > Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
>
> Yes, were you able to push this through coverity on your own?

No, I haven't.

I couldn't find any documentation on how Coverity is run for U-Boot.
Is there a recommended way to verify Coverity fixes?

Thanks and regards,
Dario
>
> --
> Tom



-- 
Dario Binacchi
Senior Embedded Software Engineer
M. +39 328 0625246
dario.binacchi@amarulasolutions.com
―――――――――――――――
Amarula Solutions SRL
 Via Felice Cavallotti 25D, 41012 Carpi, MO, IT
info@amarulasolutions.com
www.amarulasolutions.com

Re: [PATCH] test: cmd: part: fix integer handling in setup_gpt_partitions()

[Tom Rini]

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

On Sat, Jun 27, 2026 at 07:24:24PM +0200, Dario Binacchi wrote:
> On Fri, Jun 26, 2026 at 11:58 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Jun 26, 2026 at 08:40:36PM +0200, Quentin Schulz wrote:
> > > Hi Dario,
> > >
> > > On 6/26/26 8:33 PM, Dario Binacchi wrote:
> > > > Coverity reports an INTEGER_OVERFLOW issue because ut_asserteq() compares
> > > > an unsigned int (mmc_dev_num) with ret, which can hold a negative error
> > > > code.
> > > >
> > >
> > > The trick here is that ut_asserteq() takes two arguments and casts both as
> > > unsigned int, hence why it complains.
> > >
> > > If Coverity is happy, I'm happy :)
> > >
> > > This looks fine to me, so:
> > >
> > > Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
> >
> > Yes, were you able to push this through coverity on your own?
> 
> No, I haven't.
> 
> I couldn't find any documentation on how Coverity is run for U-Boot.
> Is there a recommended way to verify Coverity fixes?

There isn't, because AFAICT there's no way to do "test" builds to see if
a change corrects the problem. And I don't have this running via CI
because due to our codebase size, I think we'd be limited to 2 runs per
day, at most.

-- 
Tom

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

Re: [PATCH] test: cmd: part: fix integer handling in setup_gpt_partitions()

[Simon Glass]

Hi Tom,

On Sat, 27 Jun 2026 at 18:31, Tom Rini <trini@konsulko.com> wrote:
>
> On Sat, Jun 27, 2026 at 07:24:24PM +0200, Dario Binacchi wrote:
> > On Fri, Jun 26, 2026 at 11:58 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Jun 26, 2026 at 08:40:36PM +0200, Quentin Schulz wrote:
> > > > Hi Dario,
> > > >
> > > > On 6/26/26 8:33 PM, Dario Binacchi wrote:
> > > > > Coverity reports an INTEGER_OVERFLOW issue because ut_asserteq() compares
> > > > > an unsigned int (mmc_dev_num) with ret, which can hold a negative error
> > > > > code.
> > > > >
> > > >
> > > > The trick here is that ut_asserteq() takes two arguments and casts both as
> > > > unsigned int, hence why it complains.
> > > >
> > > > If Coverity is happy, I'm happy :)
> > > >
> > > > This looks fine to me, so:
> > > >
> > > > Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
> > >
> > > Yes, were you able to push this through coverity on your own?
> >
> > No, I haven't.
> >
> > I couldn't find any documentation on how Coverity is run for U-Boot.
> > Is there a recommended way to verify Coverity fixes?
>
> There isn't, because AFAICT there's no way to do "test" builds to see if
> a change corrects the problem. And I don't have this running via CI
> because due to our codebase size, I think we'd be limited to 2 runs per
> day, at most.

Is there a paid option for this? It is hard to tell from their
website. I would really like to be able to run coverity before sending
patches, since this business of fixing it up afterwards is quite
painful and I ended up giving up. It it doesn't cost too much I could
cover the cost.

Regards,
Simon

Re: [PATCH] test: cmd: part: fix integer handling in setup_gpt_partitions()

[Quentin Schulz]

Hi Tom,

On 6/26/26 11:58 PM, Tom Rini wrote:
> On Fri, Jun 26, 2026 at 08:40:36PM +0200, Quentin Schulz wrote:
>> Hi Dario,
>>
>> On 6/26/26 8:33 PM, Dario Binacchi wrote:
>>> Coverity reports an INTEGER_OVERFLOW issue because ut_asserteq() compares
>>> an unsigned int (mmc_dev_num) with ret, which can hold a negative error
>>> code.
>>>
>>
>> The trick here is that ut_asserteq() takes two arguments and casts both as
>> unsigned int, hence why it complains.
>>
>> If Coverity is happy, I'm happy :)
>>
>> This looks fine to me, so:
>>
>> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
> 
> Yes, were you able to push this through coverity on your own?
> 

I understand this could be misunderstood as I ran Coverity on it, but no 
I didn't. Read as "If this makes Coverity happy, then I'm happy".

Sorry for the confusion.

Cheers,
Quentin

Re: [PATCH] test: cmd: part: fix integer handling in setup_gpt_partitions()

[Tom Rini]

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

On Wed, Jul 01, 2026 at 12:57:49PM +0100, Simon Glass wrote:
> Hi Tom,
> 
> On Sat, 27 Jun 2026 at 18:31, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sat, Jun 27, 2026 at 07:24:24PM +0200, Dario Binacchi wrote:
> > > On Fri, Jun 26, 2026 at 11:58 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Jun 26, 2026 at 08:40:36PM +0200, Quentin Schulz wrote:
> > > > > Hi Dario,
> > > > >
> > > > > On 6/26/26 8:33 PM, Dario Binacchi wrote:
> > > > > > Coverity reports an INTEGER_OVERFLOW issue because ut_asserteq() compares
> > > > > > an unsigned int (mmc_dev_num) with ret, which can hold a negative error
> > > > > > code.
> > > > > >
> > > > >
> > > > > The trick here is that ut_asserteq() takes two arguments and casts both as
> > > > > unsigned int, hence why it complains.
> > > > >
> > > > > If Coverity is happy, I'm happy :)
> > > > >
> > > > > This looks fine to me, so:
> > > > >
> > > > > Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
> > > >
> > > > Yes, were you able to push this through coverity on your own?
> > >
> > > No, I haven't.
> > >
> > > I couldn't find any documentation on how Coverity is run for U-Boot.
> > > Is there a recommended way to verify Coverity fixes?
> >
> > There isn't, because AFAICT there's no way to do "test" builds to see if
> > a change corrects the problem. And I don't have this running via CI
> > because due to our codebase size, I think we'd be limited to 2 runs per
> > day, at most.
> 
> Is there a paid option for this? It is hard to tell from their
> website. I would really like to be able to run coverity before sending
> patches, since this business of fixing it up afterwards is quite
> painful and I ended up giving up. It it doesn't cost too much I could
> cover the cost.

This would be another example of things that the project should decide
where money is spent, and not individuals. You are quite welcome to make
a monetary donation to either SFC or U-Boot as well. Thanks.

-- 
Tom

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