From owner-svn-src-head@FreeBSD.ORG Wed Nov 28 23:14:52 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4CE225CD; Wed, 28 Nov 2012 23:14:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id CB7658FC14; Wed, 28 Nov 2012 23:14:51 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qASNEZgb021539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 10:14:42 +1100 Date: Thu, 29 Nov 2012 10:14:35 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andre Oppermann Subject: Re: svn commit: r243631 - in head/sys: kern sys In-Reply-To: <50B68F97.3010206@freebsd.org> Message-ID: <20121129100035.P1734@besplex.bde.org> References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50B64BE8.3040708@rice.edu> <50B68F97.3010206@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=LfNkcUji c=1 sm=1 a=PcN1GEuqyV8A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=Y5AXMyR2jB0A:10 a=2YkA8vpbpZSPZ7cIIj4A:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Alan Cox X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 23:14:52 -0000 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