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

[Conrad Meyer]

On Tue, Nov 10, 2015 at 7:08 AM, Ian Lepore <ian at freebsd.org> wrote:
> On Tue, 2015-11-10 at 08:44 +0100, Hans Petter Selasky wrote:
>> > -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?
>
> 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.

+1 to what Ian said.

In any C99 implementation where intptr_t is defined, I believe
intmax_t must be at least as big.  See § 7.18.1.5, "Greatest-width
integer types," and § 7.18.1.4, "Integer types capable of holding
object pointers."

> The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer: intptr_t
>
> The following type designates a signed integer type capable of representing any value of any signed integer type: intmax_t

Given that intptr_t exists in our implementation and is a signed
integer type, I see no reason why intmax_t could possibly not
represent any such value.  Same argument for the unsigned variants.

Best,
Conrad