Re: [Xen-devel] [PATCH v9 1/5] xen: introduce ptrdiff_t, fix uintptr_t

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.02.19 at 16:32, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 12/02/2019 15:26, Ian Jackson wrote:
>>
>>> But if we really want to have ptrdiff_t, then I think we should either
>>> follow the uintptr_t model and use attribute((mode())), or we should
>>> leverage the compiler's __PTRDIFF_TYPE__ (and then also
>>> __UINTPTR_TYPE__ for uintptr_t, at least if available - not sure what
>>> its availability depends on, but it's conditional in gcc's
>>> c_stddef_cpp_builtins()).
>> It is not unusual for porting something like Xen to a new architecture
>> to involve writing a short header file with these kind of type
>> definitions.  I don't know why we couldn't take that approach.
> 
> stdint.h and inttypes.h are a freestanding header files, and are
> intended for uses just like this.
> 
> Lets stop second guessing our build environment, and use the solution to
> the problem given to us by the C specification.
> 
> And to be crystal clear.  This means including <stdint.h> and
> <inttypes.h> in xen/types.h and deleting all of these typedefs

Well, this would certainly be a viable route if
- these headers were truly freestanding (rather than coming in their
  own incarnation with every gcc version, and perhaps also with
  any other compiler)
- were guaranteed bug free on every distro we care about building on

As an aside, inttypes.h does not seem to be part of the headers
required to be provided by a free standing compiler implementation.
Yet I think no good can come from out of sync inttypes.h and
stdint.h.

I assume you did read chapter 2 "Language Standards Supported
by GCC" of the gcc documentation, just to see their statement of
what they (mean to) support in such a case (and what they don't).

Jan



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