Date: Wed, 11 Nov 2015 03:35:29 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Hans Petter Selasky <hps@selasky.org> Cc: Bruce Evans <brde@optusnet.com.au>, "Conrad E. Meyer" <cem@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r290613 - head/sys/compat/linuxkpi/common/include/linux Message-ID: <20151111033159.O2914@besplex.bde.org> In-Reply-To: <5641A056.2040805@selasky.org> References: <201511091650.tA9Gog7d061645@repo.freebsd.org> <20151110080516.M4088@besplex.bde.org> <5641A056.2040805@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Nov 2015, Hans Petter Selasky wrote: > On 11/09/15 22:17, Bruce Evans wrote: >> ... >> This shouldn't compile either. > >> static int >> -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? Then it wouldn't be large enough to hold int64_t on i386 or intmax_t on all arches. intmax_t is already not large enough to hold uintmax_t. intmax_t can hold more than intptr_t, but its size and rank may be smaller. See another reply. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151111033159.O2914>