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

["Jan Beulich" <jbeulich@suse.com>]

>>> Ian Jackson <ian.jackson@citrix.com> 03/07/19 4:44 PM >>>
>Jan Beulich writes ("Re: [PATCH v11 1/9] xen: use __UINTPTR_TYPE__ for uintptr_t"):
>> On 06.03.19 at 22:16, <sstabellini@kernel.org> 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.

Well, I'm trying to claim that I sort of understand what their understanding
is, ...


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

... knowing some (hopefully enough) of these internals, first and foremost
because I had done the entire tool chain port for an experimental OS of
ours years ago. Arguably this may not be enough, but I hope it explains
why I'm saying what I say.


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

I'm not relying on just the what you call "vague" text. I'm having a rather
hard time imagining why the compiler folks would change a fundamental
concept of how the compiler (internally, and exposed to users via the
__attribute__(())) works.


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

He sort of did that, by pointing at them instead of quoting.


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

The fact that the symbol is not defined unconditionally, whereas
__attribute__((__mode__(__pointer__))) is always available.


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

Well, I accept this to be one possible and valid standpoint. I don't accept
this to be the only one.

Jan




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