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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:25 UTC