All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sameeruddin Shaik <sameeruddin.shaik8@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>,
	Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: [PATCH] libtracefs: An API to set the filtering of functions
Date: Tue, 9 Mar 2021 05:23:00 +0530	[thread overview]
Message-ID: <CAK7tX=ZKTRfcDs=TRTdo7dX5H7EeFeOVitX0hOPDMVYrAyP6hw@mail.gmail.com> (raw)
In-Reply-To: <20210306100525.5818bde6@oasis.local.home>

>We are happy to have you working with us.
>
>I asked because the API you happened to pick is probably the most
>complex one to implement compared to some of the other APIs listed in the
>bugzilla, which is why I asked if you planned on doing anything with it, as
>it is also one of the more crucial APIs to get right.

At first I thought, my work will be done, if I write to that file, but
complexity
increased gradually, but let me try, since i have started i will finish this.

>So yes, let's go with "const char **" as we want to show that the
>strings will not be modified, and have "const char ***" for errs.

okay then i will change the errors declaration alone.

Thanks
sameer.

On Sat, Mar 6, 2021 at 8:35 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Sat, 6 Mar 2021 07:25:18 +0530
> Sameeruddin Shaik <sameeruddin.shaik8@gmail.com> wrote:
>
> > i have one doubt.
> > >Note, @filters should be of type: const char * const * filters,  as not
> > >only is filters pointing to constant strings, the array itself will not be
> > >modified.
> >
> > what If the user wants to capture the filters at run time like below ?
> > let's say
> >
> >   filters = malloc(sizeof(char *));
> >         if (!filters)
> >                 return 1;
> >         printf("please enter the input filters count\n");
> >         scanf("%d", &fil_count);
> >         while(i < fil_count) {
> >                 scanf("%s", buf);
> >                 slen = strlen(buf);
> >                 if (!slen)
> >                         return 1;
> >                 filters[i] = calloc(1, slen);
> >                 strncpy(filters[i++], buf, slen);
> >         }
> > at that time, this declaration will be problematic right?, because we
> > are trying to modify
> > the read-only memory. Are we expecting the user to supply filters at
> > compile time like below?
> > const char * const *filters = {"kvm_pmu_reset", "kvm_pmu_init",
> > "dir_item_err", NULL};
>
> OK, my apologies, I see the issue that you are having, and you are
> correct.
>
> Because newer compiles will warn if you pass "char **" to a
> "const char * const *" parameter. Because it assumes that the two types
> are different, even when they shouldn't be. I'm not sure why the
> compiler wont let you pass in a char ** to a const char * const *, but
> it does indeed make them different.
>
> Even though there's ways to always pass strings via this logic, (you
> can create a "const char **" array and assign it to the dynamic one,
> and pass that in just fine). I looked at other prototypes, and see that
> the common method is.
>
>  const char **
>
> A couple do the "const char * const *" but they look to be special
> cases.
>
> So yes, let's go with "const char **" as we want to show that the
> strings will not be modified, and have "const char ***" for errs.
>
> Thanks!
>
> -- Steve

  reply	other threads:[~2021-03-07 23:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-06 11:20 [PATCH] libtracefs: An API to set the filtering of functions Sameeruddin shaik
2021-03-05 12:20 ` Tzvetomir Stoyanov
2021-03-05 14:39   ` Steven Rostedt
2021-03-05 14:54     ` Steven Rostedt
2021-03-06  1:55       ` Sameeruddin Shaik
2021-03-06  3:39         ` Steven Rostedt
2021-03-06  4:29           ` Sameeruddin Shaik
2021-03-06  5:19             ` Steven Rostedt
2021-03-06 15:05         ` Steven Rostedt
2021-03-08 23:53           ` Sameeruddin Shaik [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-03-10 16:21 Sameeruddin shaik
2021-03-10  5:28 ` Tzvetomir Stoyanov
2021-03-10 16:51 ` Sameeruddin Shaik
2021-03-10  5:28   ` Tzvetomir Stoyanov
2021-03-02 17:15 Sameeruddin shaik
2021-03-01 18:17 ` Steven Rostedt
2021-03-02  4:21   ` Tzvetomir Stoyanov
2021-03-02  5:14     ` Sameeruddin Shaik
2021-03-02 13:15       ` Steven Rostedt
2021-03-03  1:16   ` Sameeruddin Shaik
2021-03-02  1:28     ` Steven Rostedt
2021-03-04  8:59       ` Tzvetomir Stoyanov
2021-03-04  9:43         ` Sameeruddin Shaik

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='CAK7tX=ZKTRfcDs=TRTdo7dX5H7EeFeOVitX0hOPDMVYrAyP6hw@mail.gmail.com' \
    --to=sameeruddin.shaik8@gmail.com \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tz.stoyanov@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.