Re: [Xen-devel] [PATCH v11 1/9] xen: use __UINTPTR_TYPE__ for uintptr_t

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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