[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.