On 05/03/2019 22:38, Stefano Stabellini wrote: > Use __UINTPTR_TYPE__ to define uintptr_t. A later patch will make use of > __PTRDIFF_TYPE__ to define ptrdiff_t. > > Signed-off-by: Stefano Stabellini <stefa...@xilinx.com> > Reviewed-by: Ian Jackson <ian.jack...@eu.citrix.com> > CC: jbeul...@suse.com > CC: andrew.coop...@citrix.com > CC: julien.gr...@arm.com > CC: george.dun...@eu.citrix.com > CC: ian.jack...@eu.citrix.com > CC: konrad.w...@oracle.com > CC: t...@xen.org > CC: wei.l...@citrix.com > --- > Changes in v11: > - split patch > --- > xen/include/xen/types.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h > index 03f0fe6..1059fab 100644 > --- a/xen/include/xen/types.h > +++ b/xen/include/xen/types.h > @@ -52,7 +52,7 @@ typedef __u32 __be32; > typedef __u64 __le64; > typedef __u64 __be64; > > -typedef unsigned int __attribute__((__mode__(__pointer__))) uintptr_t; > +typedef __UINTPTR_TYPE__ uintptr_t;
I've already raised an objected to this once, so I'm going to be very blunt and crystal clear. NACK. Stop messing around with GCC-isms and use the spec-compliant way of getting uintptr_t (and others). #include <stdint.h> That way, *any* compiler will give you a working uintptr_t, not just those which are emulating GCC's internals. This isn't rocket science, and I know all of us have better things to be doing that wasting time arguing over aspects which are unrelated to actually fixing the problem. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
