[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v11 1/9] xen: use __UINTPTR_TYPE__ for uintptr_t
>>> On 06.03.19 at 22:16, <sstabellini@xxxxxxxxxx> wrote: > On Wed, 6 Mar 2019, Jan Beulich wrote: >> >>> On 05.03.19 at 23:38, <sstabellini@xxxxxxxxxx> 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 <stefanos@xxxxxxxxxx> >> > Reviewed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> >> >> 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: I'm afraid not, as I can't bring this ... > 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]. ... in line with void c_stddef_cpp_builtins(void) { builtin_define_with_value ("__SIZE_TYPE__", SIZE_TYPE, 0); builtin_define_with_value ("__PTRDIFF_TYPE__", PTRDIFF_TYPE, 0); [...] if (INTPTR_TYPE) builtin_define_with_value ("__INTPTR_TYPE__", INTPTR_TYPE, 0); if (UINTPTR_TYPE) builtin_define_with_value ("__UINTPTR_TYPE__", UINTPTR_TYPE, 0); } > [1] https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html Note that this also says "Some of these macros may not be defined on particular systems if GCC does not provide a ‘stdint.h’ header on those systems." I have absolutely no idea under what conditions gcc may not (want to) provide stdint.h. > 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. "Obscurely defined" is rather subjective, I'd say. The "pointer" mode is precisely for this according to my understanding, and personally I find "You may also specify a mode of byte or __byte__ to indicate the mode corresponding to a one-byte integer, word or __word__ for the mode of a one-word integer, and pointer or __pointer__ for the mode used to represent pointers" sufficiently clear, and not leaving room for any (hidden) interpretation like "to imply that the things are really pointers". Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |