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

From: Brooks Davis (brooks_at_one-eyed-alien.net)
Date: 01/07/05

  • Next message: Julian Elischer: "Re: cvs commit: src/sys/kern sched_ule.c (fwd)" 
    Date: Thu, 6 Jan 2005 16:53:29 -0800
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>

    On Fri, Jan 07, 2005 at 01:36:55AM +0100, Pawel Jakub Dawidek wrote:
    > On Thu, Jan 06, 2005 at 11:58:57PM +0100, Pawel Jakub Dawidek wrote:
    > +> On Thu, Jan 06, 2005 at 11:57:19AM -0800, Brooks Davis wrote:
    > +> +> I'd argue that we might want to replace the int64_t in humanize_number
    > +> +> with intmax_t since that wouldn't change the ABI (or API due to implicit
    > +> +> casts), but would mean we wouldn't have to add a humanize_number128
    > +> +> later if some architecture grows 128-bit ints for some reason or
    > +> +> another.
    > +>
    > +> I like intmax_t also much better than int64_t, but I took it from NetBSD
    > +> and they got int64_t there. Anyway, I think we don't have to be 100%
    > +> compatible here and I'll look what can be done.
    >
    > Here is proposed patch:
    >
    > http://people.freebsd.org/~pjd/patches/humanize_number.patch
    >
    > There is one issue... I had to add '#include <stdint.h>' to libutil.h.

    That's kind of annoying. I'm not sure if breaking the API or adding
    header polution to libutil.h is better.

    All all the casts of off_t's to intmax_t's really necessicary? off_t is
    signed so the implicit cast should always be safe, espeicaly if we
    switch to intmax_t (since we're then given an absolute assurance that we
    can't overflow).

    -- 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

  • Next message: Julian Elischer: "Re: cvs commit: src/sys/kern sched_ule.c (fwd)"