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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH v11 1/9] xen: use __UINTPTR_TYPE__ for 
uintptr_t"):
> On 06.03.19 at 22:16, <sstabellini@xxxxxxxxxx> wrote:
> > 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,

Unfortunately it is not your understanding that is relevant, but the
possible future understanding of compiler authors.

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

The problem is the word `mode'.  I cannot find a definition of that in
this context in the GCC manual.  The only thing is the extremely
informal description you quote.  Normally in English `mode' would mean
something other than merely `size'.

I think in fact the word `mode' here is a reference to a concept in
the GCC compiler internals.  This is really not a situation we should
be optimistic about, particularly given that we are in serious dispute
with compiler authors about the meanings of specifications and that
compiler authors seem quite willing to engage in rank sophistry.
Relying on our good faith interpretation of some vague text is a
seriously bad idea.

On the other hand, the cpp documentation has this:

  __UINTPTR_TYPE__

     These macros are defined to the correct underlying types for the
     'size_t', 'ptrdiff_t', 'wchar_t', 'wint_t', 'intmax_t', ...

This is completely clear and unambiguous.

If I were Stefano I would have quoted these manual sections in my
commit message or a code comment.  I would have hoped that to be
conclusive.

> ... 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);
> }

I have no idea what this is.  Is this some piece of the cpp source
code ?  What is your point in quoting it ?

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

We do not need to worry about this.

What this means is that if the underlying gcc platform does not have a
uintptr_t then we don't get __UINTPTR_T__.  If that is the case then
we need to fix GCC, not use some random other ad-hoc compiler feature
which we hope, without clear justification, will DTRT.

Furthermore, the possible failure case with __UINTPTR_T__is an
undefined type error.  Failures due to use of the mode attribute are
unknowable because there is no real specification for it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel