On Tue, Nov 10, 2015 at 9:42 AM, Conrad Meyer <c...@freebsd.org> wrote: > On Tue, Nov 10, 2015 at 7:08 AM, Ian Lepore <i...@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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
