[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160715120231.4539632f@gandalf.local.home>
Date: Fri, 15 Jul 2016 12:02:31 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Jiri Pirko <jiri@...lanox.com>
Cc: Jiri Olsa <jolsa@...nel.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
David Ahern <dsahern@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH 1/3] perf script python: Fix string vs byte array
resolving
On Fri, 15 Jul 2016 17:51:10 +0200
Jiri Pirko <jiri@...lanox.com> wrote:
> Fri, Jul 15, 2016 at 09:29:55AM CEST, jolsa@...nel.org wrote:
> >Jirka reported that python code returns all arrays as strings.
> >This makes impossible to get all items for byte array tracepoint
> >field containing 0x00 value item.
> >
> >Fixing this by scanning full length of the array and returning
> >it as PyByteArray object in case non printable byte is found.
> >
> >Cc: Steven Rostedt (Red Hat) <rostedt@...dmis.org>
> >Cc: Jiri Pirko <jiri@...lanox.com>
> >Link: http://lkml.kernel.org/n/tip-22f4vhhz5uytegkggy1on8u3@git.kernel.org
> >Signed-off-by: Jiri Olsa <jolsa@...nel.org>
> >---
> > .../util/scripting-engines/trace-event-python.c | 37 ++++++++++++++++++----
> > 1 file changed, 31 insertions(+), 6 deletions(-)
> >
> >diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c
> >index 6ac6b7a33f42..1bc995de5a6d 100644
> >--- a/tools/perf/util/scripting-engines/trace-event-python.c
> >+++ b/tools/perf/util/scripting-engines/trace-event-python.c
> >@@ -386,6 +386,19 @@ exit:
> > return pylist;
> > }
> >
> >+static int is_printable_array(char *p, unsigned int len)
> >+{
> >+ unsigned int i;
> >+
> >+ if (p[len - 1] == 0)
> >+ len--;
> >+
> >+ for (i = 0; i < len - 1; i++)
> >+ if (!isprint(p[i]) && !isspace(p[i]))
> >+ return 0;
>
>
> for "AA\1\0" this returns "1" although that should return "0".
>
> orig len 4
> decremented len 3
> for:
> 0 1
>
> index 2 would not be inspected. Or am I missing something?
>
> I think that the for check should be "i < len"
Yes it should be. I think we got the two solutions mixed up.
With the above len--, it should be i < len, but when we did the check
for zero at the end, we needed the i < len - 1
-- Steve
Powered by blists - more mailing lists