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

Justin Hibbits jrh29 at alumni.cwru.edu
Tue Nov 10 17:29:48 UTC 2015


On Tue, Nov 10, 2015 at 9:42 AM, Conrad Meyer <cem at freebsd.org> wrote:
> 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
>

I may be wrong on this, but I *think* uintptr_t/intptr_t are required
to be *precisely* the same size as a pointer, which explains why you
can't cast directly from uintmax_t on 32-bit architectures.

- Justin


More information about the svn-src-all mailing list