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