On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney wrote:> Erich Dollansky wrote this message on Sun, Feb 01, 2015 at 17:51 +0800: > > int can be 64 bits on a amd64 machine. Why is the author of this code > > so sure that we will never cross the 32 bit boundary? > > Per others, int is currently 32bits on all platforms we support... > > I guess adding: > CTASSERT(sizeof(int) <= 4); > > would help fix your concern? at least now the expectation is codified > and if it breaks, the build will break.. > > -- > John-Mark Gurney Voice: +1 415 225 5579 >If/when the size of an int ever changes from being 32 bits, top will be the least of our worries! Bob -- Bob Willcox | You climb to reach the summit, but once bob at immure.com | there, discover that all roads lead down. Austin, TX | -- Stanislaw Lem, "The Cyberiad"
Hi, On Tue, 10 Feb 2015 17:14:41 -0600 Bob Willcox <bob at immure.com> wrote:> On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney wrote: > > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at 17:51 > > +0800: > > > int can be 64 bits on a amd64 machine. Why is the author of this > > > code so sure that we will never cross the 32 bit boundary? > > > > Per others, int is currently 32bits on all platforms we support... > > > > I guess adding: > > CTASSERT(sizeof(int) <= 4); > > > > would help fix your concern? at least now the expectation is > > codified and if it breaks, the build will break.. > > > > -- > > John-Mark Gurney Voice: +1 415 225 > > 5579 > > > > If/when the size of an int ever changes from being 32 bits, top will > be the least of our worries! >if all dubious statements have asserts in place, nothing will be a worry until then. It is a very bad idea to assume a size for any type when the size can change between compilers. If you want, just read the old discussion regarding time_t. Erich