Date: Thu, 29 Nov 2012 10:14:35 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Andre Oppermann <andre@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Alan Cox <alc@rice.edu> Subject: Re: svn commit: r243631 - in head/sys: kern sys Message-ID: <20121129100035.P1734@besplex.bde.org> In-Reply-To: <50B68F97.3010206@freebsd.org> References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50B64BE8.3040708@rice.edu> <50B68F97.3010206@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Nov 2012, Andre Oppermann wrote: > On 28.11.2012 18:37, Alan Cox wrote: >> I'm pretty sure that the "realmem" calculation is going to overflow on >> i386/PAE, where the number of bytes of physical memory is greater than >> the type long can represent. > > Right. long == int on i386/PAE, not LP64. Is uint64_t the correct type > to use to catch that? No. 2**63-1 bytes of physical memory might be enough for anyone, but more than that is is useful for virtual memory, and there is no need to ensure that P128 will be broken when it exists. I would just use sizes in pages for everything so that 32-bit u_ints are enough. Although this may break before P128 exists. Otherwise, uintmax_t should be used. Sloppy code can also depend on uintmax_t being "infinitely" large, so that multiplications by small scale factors don't overflow (use the more natural 'foo = bar * 3 / 4;' instead of 'foo = bar / 4 * 3;', but this can still overflow if bar is user input (say a tunable) that is not already limited enough. vm_paddr_t could be used for physical memory sizes, but might be too small or too large for virtual memory sizes, so using it would often give the same bloat as using uintmax_t, and more complications than using either u_int or uintmax_t for everything. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121129100035.P1734>