svn commit: r290613 - head/sys/compat/linuxkpi/common/include/linux

[Ian Lepore]

On Tue, 2015-11-10 at 08:44 +0100, Hans Petter Selasky wrote:
> On 11/09/15 22:17, Bruce Evans wrote:
> > On Mon, 9 Nov 2015, Conrad E. Meyer wrote:
> > 
> > > Log:
> > >  linuxkpi/sysfs.h: Cast arg2 through intptr_t to avoid GCC
> > > warning
> > > 
> > >  The code compiles fine under Clang, but GCC on PPC is less
> > > permissive
> > > about
> > >  integer and pointer sizes.  (An intmax_t is clearly *large
> > > enough* to
> > > hold a
> > >  pointer value.)
> > > 
> > >  Another follow-up to r290475.
> > 
> > This shouldn't compile either.
> > 
> 
> Hi Conrad,
> 
> 
> >  static int
> > -sysctl_root_handler_locked(struct sysctl_oid *oid, void *arg1,
> > intptr_t arg2,
> > +sysctl_root_handler_locked(struct sysctl_oid *oid, void *arg1,
> > intmax_t arg2,
> >      struct sysctl_req *req, struct rm_priotracker *tracker)
> 
> Given that the second argument is sometimes used for pointers, maybe
> we 
> should keep it intptr_t. Or add a compile time assert that 
> sizeof(intmax) >= sizeof(intptr_t) which I think doesn't hold?
> 
> --HPS
> 

If intmax_t is the "maximum width integer type" and intptr_t is
"integer type capable of holding a pointer", I think by definition
sizeof(intmax_t) must be >= sizeof(intptr_t).  On the other hand, given
the perverse way standards-writers think, I'm not sure "big enough" is
all it takes to qualify as "capable of holding a pointer".  But I think
in reality it'll work out right anyway.

-- Ian