Re: [Qemu-trivial] [Qemu-devel] [PATCH 03/12] hw/pci/pci_host.c: Avoid shifting left into sign bit

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Mar 10, 2014 at 09:03:08PM +0100, Stefan Weil wrote:
> Am 10.03.2014 20:10, schrieb Peter Maydell:
> > Add U suffix to avoid undefined behaviour.
> > 
> > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> > ---
> >  hw/pci/pci_host.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/pci/pci_host.c b/hw/pci/pci_host.c
> > index 77c7d1f..2c17916 100644
> > --- a/hw/pci/pci_host.c
> > +++ b/hw/pci/pci_host.c
> > @@ -142,8 +142,9 @@ static uint64_t pci_host_data_read(void *opaque,
> >  {
> >      PCIHostState *s = opaque;
> >      uint32_t val;
> > -    if (!(s->config_reg & (1 << 31)))
> > +    if (!(s->config_reg & (1u << 31))) {
> >          return 0xffffffff;
> 
> I suggest fixing that 0xffffffff, too. Do we expect here a 32 bit value
> (-1) which is expanded to a 64 bit value? Then 0xffffffffffffffffULL
> would be correct. Otherwise 0xffffffffU is clearer.

Hmm why is this clearer?  The spec says:

	The type of an integer constant is the first of the corresponding list
	in which its value can be represented.

Basically 0x<anything> is always a positive value and when cast to
uint64_t is not sign extended.


> Michael, are 8 byte reads possible here? If yes, the current code is wrong.

AFAIK they aren't possible on any platform we support.
So since we discard high bits 0 seems cleaner.

> > +    }
> >      val = pci_data_read(s->bus, s->config_reg | (addr & 3), len);
> >      PCI_DPRINTF("read addr " TARGET_FMT_plx " len %d val %x\n",
> >                  addr, len, val);
> > 
> 
> What about using the BIT macro from qemu/bitops.h? I think that BIT(31)
> looks better than (1u << 31).
> 
> Stefan

I slightly prefer 1u << 31 personally, standard C as opposed to qemu macros.


-- 
MST