qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/8] 9pfs: fix P9_NOTAG and P9_NOFID macros


From: Greg Kurz
Subject: Re: [Qemu-devel] [PATCH 3/8] 9pfs: fix P9_NOTAG and P9_NOFID macros
Date: Sat, 10 Dec 2016 14:57:08 +0100

On Fri, 9 Dec 2016 15:25:55 -0600
Eric Blake <address@hidden> wrote:

> On 12/09/2016 03:28 AM, Greg Kurz wrote:
> > The u16 and u32 types don't exist in QEMU common headers. It never broke
> > build because these two macros aren't use by the current code, but this
> > is about to change with the future addition of functional tests for 9P.
> > 
> > This patch convert the types to uintXX_t.
> > 
> > Signed-off-by: Greg Kurz <address@hidden>
> > ---
> >  hw/9pfs/9p.h |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
> > index 3976b7fe3dcd..89c904bdb7e7 100644
> > --- a/hw/9pfs/9p.h
> > +++ b/hw/9pfs/9p.h
> > @@ -99,8 +99,8 @@ enum p9_proto_version {
> >      V9FS_PROTO_2000L = 0x02,
> >  };
> >  
> > -#define P9_NOTAG    (u16)(~0)
> > -#define P9_NOFID    (u32)(~0)
> > +#define P9_NOTAG    (uint16_t)(~0)
> > +#define P9_NOFID    (uint32_t)(~0)  
> 
> Don't you want to write ((uint16_t)(~0)), to ensure that this expression
> can be used as a drop-in in any other syntactical situation?
> 

These defines come from the linux kernel sources and I must admit it
didn't cross my mind... can you share a case where this would cause
troubles ?

> Or even write it as UINT16_C(~0) (using <stdint.h>), or as UINT16_MAX.
> (Be aware: the type of (uint16_t)(~0) is uint16_t, while the type of
> UINT16_MAX is int, due to the rules of integer promotion, if that matters)
> 

UINT16_C(~0) expands to ~0 and UINT16_MAX expands to (65535), at least on
my laptop (glibc-headers-2.23.1-11.fc24.x86_64)... doesn't that mean the
type of UINT16_C(~0) is also int ? Please enlighten me.

The 9P spec at http://man.cat-v.org/plan_9/5/version says "(ushort)~0". My
understanding is 16 bits all ones. I guess I'd rather then go for
((uint16_t)(~0)).

Thanks!

--
Greg

Attachment: pgpWPe_qzvTFb.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]