Re: [Xen-devel] [PATCH] xen: correct definition of uintptr_t on 32-bit platforms.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.06.13 at 16:42, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Tue, 2013-06-04 at 15:36 +0100, Jan Beulich wrote:
>> >>> On 04.06.13 at 16:00, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> > On Tue, 2013-06-04 at 14:52 +0100, Jan Beulich wrote:
>> >> >>> On 04.06.13 at 15:16, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
>> >> > Currently uintptr_t is unsigned long for both 32- and 64- bit platforms 
> but
>> >> > __PRIPTR_PREFIX is just "" on 32-bit leading to:
>> >> > 
>> >> >     error: format '%u' expects argument of type 'unsigned int', but 
>> > argument 
>> >> > 2 has type 'long unsigned int' [-Werror=format]
>> >> > 
>> >> > It was a bit of a tossup between changing __PREPTR_PREFIX and changing 
>> >> > the
>> >> > definition of uintptr_t. I went with the latter since it is consistent 
> with
>> >> > glibc.
>> >> 
>> >> Actually I would much prefer the format string prefix to be changed
>> >> - like Linux, we're assuming all over the place that pointer and longs
>> >> are equivalent in size, so creating an association between pointers
>> >> and ints is much more likely to cause problems than adjusting the
>> >> format string prefix.
>> > 
>> > Can do that if you prefer.
>> > 
>> > Would this just push the problem into the code which is compiled for
>> > both user and hypervisor space (e.g. libelf), uintptr_t would then be
>> > different in the two environments. I haven't tried it so I don't know
>> > what the practical impact is.
>> 
>> In user environment the print format should be taken from the
>> standard C headers just as the uintptr_t definition ought to be.
>> No risk of collision if done consistently.
> 
> Yes, absolutely.
> 
> I was thinking more of "assignment from incompatible... " type errors,
> where fixing one case would break the other...

Ah, okay - that risk exists no matter what type we pick, as it's
not just Linux our user mode stuff gets built on.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel