From: Namhyung Kim <namhyung@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Namhyung Kim <namhyung.kim@lge.com>
Subject: Re: [PATCH 01/14] tools lib traceevent: Get rid of malloc_or_die() in show_error()
Date: Tue, 10 Dec 2013 11:03:44 +0900 [thread overview]
Message-ID: <87mwk9jwcf.fsf@sejong.aot.lge.com> (raw)
In-Reply-To: <20131209142350.5d23108c@gandalf.local.home> (Steven Rostedt's message of "Mon, 9 Dec 2013 14:23:50 -0500")
On Mon, 9 Dec 2013 14:23:50 -0500, Steven Rostedt wrote:
> On Mon, 9 Dec 2013 16:14:39 -0300
> Arnaldo Carvalho de Melo <acme@ghostprotocols.net> wrote:
>
>> Em Mon, Dec 09, 2013 at 02:03:42PM -0500, Steven Rostedt escreveu:
>> > On Mon, 9 Dec 2013 15:30:09 -0300
>> > Arnaldo Carvalho de Melo <acme@ghostprotocols.net> wrote:
>> >
>> >
>> > > > + error = malloc(MAX_ERR_STR_SIZE);
>> > > > + if (error == NULL) {
>> > > > + /* no memory */
>> > > > + *error_str = "failed to allocate memory";
>> > > > + return;
>> > >
>> > > Can *error_str point to either malloc'ed or constant strings? Who
>> > > releases the allocated memory?
>> > >
>> >
>> > Good question. Perhaps we should have a flag that states if the string
>> > is allocated or not. Or better yet, since the only reason it would be
>> > pointing to a static string is if the string for error_str itself
>> > failed to allocate. Then we could use a string within pevent for it:
>> >
>> > static char *pevent_failed_error_alloc = "failed to allocate memory";
>> >
>> > Then in the freeing of error str:
>> >
>> > void pevent_free_error_str(error_str)
>> > {
>> > if (error_str != pevent_failed_error_alloc)
>> > free(error_str);
>> > }
>>
>> That is a possibility, yes, then any other routine that works in such a
>> way could check against this string, but what is wrong with returning a
>> value to that function and checking against < 0?
>
> Then everyone has to check if show_error() failed. Then report a bug if
> it did. Egad, then we need to check if that error function failed, and
> then that one and that one and that one :-)
What about returning error code rather than string? This way we won't
worry about the allocation of the error string itself.
But the downside of it is loosing a positional info of the error.
Hmm.. what about using a static buffer in pevent for it then?
Thanks,
Namhyung
next prev parent reply other threads:[~2013-12-10 2:03 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 5:33 [PATCHSET 00/14] tools lib traceevent: Get rid of *die() calls from parse-filter.c Namhyung Kim
2013-12-09 5:33 ` [PATCH 01/14] tools lib traceevent: Get rid of malloc_or_die() in show_error() Namhyung Kim
2013-12-09 18:30 ` Arnaldo Carvalho de Melo
2013-12-09 19:03 ` Steven Rostedt
2013-12-09 19:14 ` Arnaldo Carvalho de Melo
2013-12-09 19:23 ` Steven Rostedt
2013-12-10 2:03 ` Namhyung Kim [this message]
2013-12-10 2:14 ` Steven Rostedt
2013-12-10 5:01 ` Namhyung Kim
2013-12-10 5:30 ` Namhyung Kim
2013-12-11 0:40 ` Namhyung Kim
2013-12-11 1:55 ` Steven Rostedt
2013-12-11 2:29 ` Namhyung Kim
2013-12-12 1:10 ` Steven Rostedt
2013-12-09 5:33 ` [PATCH 02/14] tools lib traceevent: Get rid of die in add_filter_type() Namhyung Kim
2013-12-09 10:44 ` Jiri Olsa
2013-12-10 0:32 ` Namhyung Kim
2013-12-09 5:34 ` [PATCH 03/14] tools lib traceevent: Get rid of malloc_or_die() in pevent_filter_alloc() Namhyung Kim
2013-12-11 11:05 ` [tip:perf/core] " tip-bot for Namhyung Kim
2013-12-09 5:34 ` [PATCH 04/14] tools lib traceevent: Get rid of malloc_or_die() allocate_arg() Namhyung Kim
2013-12-09 16:05 ` Steven Rostedt
2013-12-10 1:21 ` Namhyung Kim
2013-12-10 2:08 ` Steven Rostedt
2013-12-09 5:34 ` [PATCH 05/14] tools lib traceevent: Get rid of malloc_or_die() in read_token() Namhyung Kim
2013-12-09 5:34 ` [PATCH 06/14] tools lib traceevent: Get rid of malloc_or_die() in find_event() Namhyung Kim
2013-12-09 11:03 ` Jiri Olsa
2013-12-09 16:27 ` Steven Rostedt
2013-12-10 0:48 ` Namhyung Kim
2013-12-09 5:34 ` [PATCH 07/14] tools lib traceevent: Get rid of malloc_or_die() in add_event() Namhyung Kim
2013-12-11 11:06 ` [tip:perf/core] " tip-bot for Namhyung Kim
2013-12-09 5:34 ` [PATCH 08/14] tools lib traceevent: Get rid of die() in create_arg_item() Namhyung Kim
2013-12-11 11:06 ` [tip:perf/core] " tip-bot for Namhyung Kim
2013-12-09 5:34 ` [PATCH 09/14] tools lib traceevent: Get rid of die() in add_right() Namhyung Kim
2013-12-09 6:28 ` Ilia Mirkin
2013-12-09 6:59 ` Namhyung Kim
2013-12-09 16:32 ` Steven Rostedt
2013-12-09 23:47 ` Namhyung Kim
2013-12-09 5:34 ` [PATCH 10/14] tools lib traceevent: Get rid of die() in reparent_op_arg() Namhyung Kim
2013-12-09 5:34 ` [PATCH 11/14] tools lib traceevent: Get rid of malloc_or_die() in pevent_filter_add_filter_str() Namhyung Kim
2013-12-11 11:06 ` [tip:perf/core] " tip-bot for Namhyung Kim
2013-12-09 5:34 ` [PATCH 12/14] tools lib traceevent: Get rid of die() in pevent_filter_clear_trivial() Namhyung Kim
2013-12-11 11:06 ` [tip:perf/core] " tip-bot for Namhyung Kim
2013-12-09 5:34 ` [PATCH 13/14] tools lib traceevent: Refactor test_filter() to get rid of die() Namhyung Kim
2013-12-09 16:19 ` Steven Rostedt
2013-12-10 1:48 ` Namhyung Kim
2013-12-09 5:34 ` [PATCH 14/14] tools lib traceevent: Get rid of die() in some string conversion funcitons Namhyung Kim
2013-12-09 16:24 ` Steven Rostedt
2013-12-10 1:50 ` Namhyung Kim
2013-12-09 10:47 ` [PATCHSET 00/14] tools lib traceevent: Get rid of *die() calls from parse-filter.c Jiri Olsa
2013-12-09 16:40 ` Steven Rostedt
2013-12-09 16:24 ` Steven Rostedt
2013-12-09 18:41 ` Arnaldo Carvalho de Melo
2013-12-10 0:34 ` Namhyung Kim
-- strict thread matches above, loose matches on Subject: below --
2013-12-12 7:36 [PATCHSET 00/14] tools lib traceevent: Get rid of *die() calls from parse-filter.c (v2) Namhyung Kim
2013-12-12 7:36 ` [PATCH 01/14] tools lib traceevent: Get rid of malloc_or_die() in show_error() Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mwk9jwcf.fsf@sejong.aot.lge.com \
--to=namhyung@kernel.org \
--cc=acme@ghostprotocols.net \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung.kim@lge.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox