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 _______________________________________________ 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"
