Date: Thu, 6 Jan 2005 22:46:30 +0200 From: Giorgos Keramidas <keramida@freebsd.org> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: freebsd-current@freebsd.org Subject: Re: human-readable swap partition sizes with pstat -sh Message-ID: <20050106204630.GA35307@gothmog.gr> In-Reply-To: <20050106200718.GD24896@odin.ac.hmc.edu> References: <20050106191201.GA30826@gothmog.gr> <20050106195719.GB24896@odin.ac.hmc.edu> <20050106195950.GA34916@gothmog.gr> <20050106200718.GD24896@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2005-01-06 12:07, Brooks Davis <brooks@one-eyed-alien.net> wrote: > On Thu, Jan 06, 2005 at 09:59:50PM +0200, Giorgos Keramidas wrote: > > > On minor, mostly style nit is that while intmax_t is 64-bits, nothing > > > requires that so you should probably have conver return an int64_t. > > > > I lost you a bit here. > > The CONVERT macro used to case to (int). You removed that cast which > works because humanize_number takes an int64_t and intmax_t is the same > as int64_t on all architectures. I was suggesting that you should case > to int64_t. Alternativly, humanize_number could be fixed. I can't > think of any useful reason to add the complexity of 128-bit ints to > general purpose CPUs so this is probalby mostly paranoia. Ah, I see now. I didn't like the explicit cast to (int) because significant bits may be lost if sizeof(int) < sizeof(intmax_t) (which is true on all the architectures FreeBSD runs on now, IIRC). Adding an (int64_t) cast won't avoid the possibility of having problems later on when intmax_t is larger than int64_t, but you are 100% right :-) - Giorgos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050106204630.GA35307>