All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH qemu] ppc/vof: Fix Coverity issues
Date: Mon, 19 Jul 2021 22:07:10 +1000	[thread overview]
Message-ID: <YPVq7sFeM9sCzQ0W@yekko> (raw)
In-Reply-To: <8e0e013e-4043-7424-8b93-f3f144601b8c@ozlabs.ru>

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

On Mon, Jul 19, 2021 at 06:25:53PM +1000, Alexey Kardashevskiy wrote:
> 
> 
> On 7/19/21 13:57, David Gibson wrote:
> > On Tue, Jul 13, 2021 at 11:46:38PM +1000, Alexey Kardashevskiy wrote:
> > > This fixes NEGATIVE_RETURNS, OVERRUN issues reported by the Coverity.
> > > 
> > > This adds a comment about the return parameters number in the VOF hcall.
> > > The reason for such counting is to keep the numbers look the same in
> > > vof_client_handle() and the Linux (an OF client).
> > > 
> > > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > > ---
> > > 
> > > Will this make COverity happy? What is the canonical way of fixing these
> > > uint32_t vs. int? Thanks,
> > 
> > It might make Coverity happy, but I think it's an ugly approach.
> > 
> > > 
> > > ---
> > >   hw/ppc/vof.c | 12 ++++++++----
> > >   1 file changed, 8 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/hw/ppc/vof.c b/hw/ppc/vof.c
> > > index 81f65962156c..872f671babbe 100644
> > > --- a/hw/ppc/vof.c
> > > +++ b/hw/ppc/vof.c
> > > @@ -517,7 +517,7 @@ static uint32_t vof_instance_to_package(Vof *vof, uint32_t ihandle)
> > >   static uint32_t vof_package_to_path(const void *fdt, uint32_t phandle,
> > >                                       uint32_t buf, uint32_t len)
> > >   {
> > > -    uint32_t ret = -1;
> > > +    int ret = -1;
> > 
> > I don't think you want to try to use the same variable for the value
> > from phandle_to_path() and the return value from this function -
> > they're different types, with different encodings.  The inner value
> > should remain int (that's the libfdt convention).
> > 
> > The outer one is explicltly unsigned.  You're not really looking for
> > negative error values, but specifically for -1U == ~0U as the single
> > error value.  So re-introduce your PROM_ERROR valued, defined as ~0U,
> > so that it's clearly unsigned, and use that and unsigned logic for all
> > manipulation of the outer value.
> 
> 
> Fair enough. One question. Linux defines it as
> 
> #define PROM_ERROR (-1u)
> 
> Do you still vote for "~0U"?

I don't really mind.  I think (-1U) might cause some more Coverity
confusion that ~0U, based on experience with Coverity scans of dtc &
libfdt.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

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

  reply	other threads:[~2021-07-20  1:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13 13:46 [PATCH qemu] ppc/vof: Fix Coverity issues Alexey Kardashevskiy
2021-07-19  3:57 ` David Gibson
2021-07-19  8:25   ` Alexey Kardashevskiy
2021-07-19 12:07     ` David Gibson [this message]
2021-07-19  7:55 ` Greg Kurz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YPVq7sFeM9sCzQ0W@yekko \
    --to=david@gibson.dropbear.id.au \
    --cc=aik@ozlabs.ru \
    --cc=groug@kaod.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.