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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.02.19 at 11:28, <george.dunlap@xxxxxxxxxx> wrote:
> On 2/12/19 4:03 PM, Jan Beulich wrote:
>>>>> 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)
> 
> Why would this be a problem?  Isn't that a feature -- that your
> compiler/header file combination provides you with the proper runes to
> get a working uintptr_t?  That seems a lot more robust and reliable than
> trying to keep our own header that works on all possible compiler
> combinations.

Well, that depends on which instance of the header one ends up
including - the one in /usr/include/, or the specific one coming
with the specific compiler version. It is certainly possible that I'm
too biased due to my DOS / OS/2 / Windows / NetWare heritage,
where compilers didn't necessarily know where to take headers
from without being told, but I'm simply uncertain whether of all
compilers we care about (and also all ones we want to care
about in the future) we can expect that they'll find the right
headers without our help, and they won't fall back to e.g. the
ones in /usr/include/, or not find anything at all.

>> - were guaranteed bug free on every distro we care about building on
> 
> This argument seems kind of backwards to me.
> 
> You are implicitly asserting that there are distros we care about
> building on where the system stdint.h and inttypes.h have bugs.  It's
> not up to others to show that this is false, but up to you to show that
> it's true; by providing at least some examples (even if historical).
> 
> Or if you don't have examples ready to hand, saying something like:
> 
> "I seem to recall some distros having bugs in stdint.h in the past.  We
> should make sure to test it with all distro versions we care about
> before committing to it."  This should be somewhat easier now that we
> have the docker build-testing infrastructure.

Oh, that's pretty easy: Why would gcc care to produce fixed up
host headers (see the fixincludes/ subdirectory in its sources and
how it's used by the build process), if there wasn't the problem of
distros getting their headers wrong?

But then again I don't think I agree with you considering this
backwards: Bugs exist, there's no question. For something as
fundamental as producing correct basic types (which _can_ be
got right without relying on any headers outside of a project's
source tree), the mere risk of there possibly being bugs is bad
enough imo.

Jan



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