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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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

Ian.




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