On Wed, 6 Mar 2019, Jan Beulich wrote: > >>> On 05.03.19 at 23:38, <sstabell...@kernel.org> 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> > > As before - I object to this change without the description supplying > both a reason (which would better also explain why the current way > of defining uintptr_t is detrimental) and a discussion why it is okay for > us to use __UINTPTR_TYPE__, despite (at least) gcc making this > available only under certain conditions (i.e. it would need to be > confirmed that whatever the conditions they're always met for us).
Is the following good enough: Use __UINTPTR_TYPE__ to define uintptr_t for consistency with ptrdiff_t. __UINTPTR_TYPE__ is safe to use as it is a common predefined macro of GNU C; it is defined to the correct underlying type as per GCC documentation[1]. [1] https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html Also, it is not a good idea to use __mode__(__pointer__) to define uintptr_t, because it relies on an obscurely defined GCC feature whose semantics might be taken to imply that the things are really pointers. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
