[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v9 1/5] xen: introduce ptrdiff_t, fix uintptr_t
On Tue, 12 Feb 2019, Jan Beulich wrote: > >>> On 12.02.19 at 02:13, <sstabellini@xxxxxxxxxx> wrote: > > --- a/xen/include/xen/types.h > > +++ b/xen/include/xen/types.h > > @@ -52,7 +52,8 @@ typedef __u32 __be32; > > typedef __u64 __le64; > > typedef __u64 __be64; > > > > -typedef unsigned int __attribute__((__mode__(__pointer__))) uintptr_t; > > +typedef unsigned long __attribute__((__mode__(__pointer__))) uintptr_t; > > I don't understand this change: The mode attribute discards any width > association derived from the specified base type. Sorry Jan, I muddled the waters even further with this change. :-/ I genuinely thought that it was required to make the whole thing work, but it turns I was confused. I'll drop this change, except for the below. > > +typedef long ptrdiff_t; > > FTR I'm unconvinced of this, or the need to use uintptr_t in the first > place in the macros you introduce: The entire UNIX world implies > sizeof(long) == sizeof(void*) afaik. > > But if we really want to have ptrdiff_t, then I think we should either > follow the uintptr_t model and use attribute((mode())), or we should > leverage the compiler's __PTRDIFF_TYPE__ (and then also > __UINTPTR_TYPE__ for uintptr_t, at least if available - not sure what > its availability depends on, but it's conditional in gcc's > c_stddef_cpp_builtins()). I like the idea of using ptrdiff_t, it seems appropriate to me. However, I have also read the other replies about not using __attribute__((__mode__(__pointer__))). I don't have an opinion on that, but we don't have to clean-up the whole of Xen with this series alone, which is already changing a lot of code. So, I'll go with the path of least resistance. It looks like __PTRDIFF_TYPE__ and __UINTPTR_TYPE__ are a good way to do it, so I'll go with that. But I am also OK with dropping this patch from the series and using "long" and "unsigned long" instead. Like you wrote, whether it's right or wrong, the assumption sizeof(void*)==sizeof(unsigned long) is everywhere in the Xen code. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |