[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091115080833.GC15432@elte.hu>
Date: Sun, 15 Nov 2009 09:08:33 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: Hitoshi Mitake <mitake@....info.waseda.ac.jp>,
linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Paul Mackerras <paulus@...ba.org>
Subject: Re: [PATCH] perf tools: New function to parse string representing
size in bytes
* Frederic Weisbecker <fweisbec@...il.com> wrote:
> On Sun, Nov 15, 2009 at 12:50:45PM +0900, Hitoshi Mitake wrote:
> > This patch modifies util/string.[ch] to add new function: bytesexp2int()
> > to parse string representing size in bytes.
> >
> > Below is the description of bytesexp2int().
> >
> > Parse (\d+)(b|B|kb|KB|mb|MB|gb|GB) (e.g. "256MB")
> > and return its numeric value. (e.g. 268435456)
> >
> > The parameter str is not changed before and after calling,
> > but it changed temporally and internally for atoi().
> > So type of str is char *, not const char *.
> >
> > Signed-off-by: Hitoshi Mitake <mitake@....info.waseda.ac.jp>
> > Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> > Cc: Paul Mackerras <paulus@...ba.org>
> > Cc: Frederic Weisbecker <fweisbec@...il.com>
> > ---
> > tools/perf/util/string.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++
> > tools/perf/util/string.h | 1 +
> > 2 files changed, 90 insertions(+), 0 deletions(-)
> >
> > diff --git a/tools/perf/util/string.c b/tools/perf/util/string.c
> > index 04743d3..bbedb06 100644
> > --- a/tools/perf/util/string.c
> > +++ b/tools/perf/util/string.c
> > @@ -1,4 +1,5 @@
> > #include <string.h>
> > +#include <stdlib.h>
> > #include "string.h"
> >
> > static int hex(char ch)
> > @@ -43,3 +44,91 @@ char *strxfrchar(char *s, char from, char to)
> >
> > return s;
> > }
> > +
> > +static int digit(char ch)
> > +{
> > + if ('0' <= ch && ch <= '9')
> > + return 1;
> > + return 0;
> > +}
>
>
>
> We have a "isdigit" macro in util.h already, despite the even already
> existing isdigit from the libc. I don't know why we have that. I guess
> it comes from git sources but I'm not sure why it has been
> reimplemented.
Git tends to be a lot saner when it comes to keeping library functions
sane, so i'd prefer if we kept and used the Git version.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists