Date: Fri, 17 Sep 2004 15:41:46 +0700 From: Alexey Dokuchaev <danfe@nsu.ru> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: New libutil function: parse_capacity(3). Message-ID: <20040917084146.GA45371@regency.nsu.ru> In-Reply-To: <20040917081416.GL30151@darkness.comp.waw.pl> References: <20040916184201.GD30151@darkness.comp.waw.pl> <20040917040445.GA52078@regency.nsu.ru> <20040917081416.GL30151@darkness.comp.waw.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 17, 2004 at 10:14:16AM +0200, Pawel Jakub Dawidek wrote: > On Fri, Sep 17, 2004 at 11:04:45AM +0700, Alexey Dokuchaev wrote: > +> > I implemented parse_capacity() function which can be use to convert a > +> > string with a human-readable capacity value to a off_t value. > +> > > +> > It can be used by utilities like: > +> > > +> > % truncate -s 8g test > +> > # mdconfig -a -t malloc -s 16M > +> > > +> > Patch can be found here: > +> > > +> > http://people.freebsd.org/~pjd/patches/parse_capacity.patch > +> > > +> > Any comments before committing? > +> > +> Methinks you could probably come up with a better name, since > +> "engeneering number mode" (using K, M, T, etc) is used for bandwidth, > +> for instance, not just for `capacity'. IMHO. Making it that user can > +> easily guess its name from already-there humanize_number(3). > > Fell free to suggest a better one:) > I talked about this name with few people before name was choosen and > this is the list of proposals: > > - dehumanize_number(), This one is good. > - parse_humanized_humber(), And this one. > > :) > I really don't want to start bikeshed about function name here. Neither do I. I just wanted to point out that `capacity' probably isn't the best choice. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040917084146.GA45371>