Re: human-readable swap partition sizes with pstat -sh

From: Brooks Davis <brooks_at_one-eyed-alien.net>
Date: Thu, 6 Jan 2005 12:07:18 -0800
On Thu, Jan 06, 2005 at 09:59:50PM +0200, Giorgos Keramidas wrote:
> On 2005-01-06 11:57, Brooks Davis <brooks_at_one-eyed-alien.net> wrote:
> > On Thu, Jan 06, 2005 at 09:12:01PM +0200, Giorgos Keramidas wrote:
> > > The following patch adds support for human-readable partition sizes in
> > > pstat -s and swapinfo output, when the -h option is used:
> > >
> > > 	gothmog:/d/src/usr.sbin/pstat$ ./pstat -s
> > > 	Device          1K-blocks     Used    Avail Capacity
> > > 	/dev/ad1s1b       5120000       12  5120000     0%
> > >
> > > 	gothmog:/d/src/usr.sbin/pstat$ ./pstat -sh
> > > 	Device          1K-blocks     Used    Avail Capacity
> > > 	/dev/ad1s1b       5120000      12K     4.9G     0%
> > >
> > > Does anyone have comments or suggestions for further improvement?
> >
> > Look good in general.  Does -kh make sense?  I think so since it would
> > force the blocks line, but I'm not 100% sure.
> 
> It does.  -k only affects the way 'number of blocks' is printed.  The
> sizes of 'used' and 'avail' are calculated differently -- in bytes,
> otherwise humanize_number() would return bogus strings.
> 
> > 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.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

Received on Thu Jan 06 2005 - 19:05:32 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:25 UTC