Date: Tue, 10 Nov 2015 11:29:47 -0600 From: Justin Hibbits <jrh29@alumni.cwru.edu> To: cem@freebsd.org Cc: Hans Petter Selasky <hps@selasky.org>, Ian Lepore <ian@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r290613 - head/sys/compat/linuxkpi/common/include/linux Message-ID: <CAHSQbTCh3ExHQ1aCDoGwDaiUeEbr-vP5QimZOO4Nqw=Fio-Vkg@mail.gmail.com> In-Reply-To: <CAG6CVpWeVVZmkyPOK2RbhC285LfGmyGbS=51qF6g9cNSSFxn%2BA@mail.gmail.com> References: <201511091650.tA9Gog7d061645@repo.freebsd.org> <20151110080516.M4088@besplex.bde.org> <5641A056.2040805@selasky.org> <1447168083.91061.2.camel@freebsd.org> <CAG6CVpWeVVZmkyPOK2RbhC285LfGmyGbS=51qF6g9cNSSFxn%2BA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 10, 2015 at 9:42 AM, Conrad Meyer <cem@freebsd.org> wrote: > On Tue, Nov 10, 2015 at 7:08 AM, Ian Lepore <ian@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) >=3D 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 >=3D sizeof(intptr_t). On the other hand, give= n >> 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 =C2=A7 7.18.1.5, "Greatest-width > integer types," and =C2=A7 7.18.1.4, "Integer types capable of holding > object pointers." > >> The following type designates a signed integer type with the property th= at 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 represent= ing 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHSQbTCh3ExHQ1aCDoGwDaiUeEbr-vP5QimZOO4Nqw=Fio-Vkg>