Re: [rtla 04/13] rtla: Replace atoi() with a robust strtoi()

[Wander Lairson Costa <wander@redhat.com>]

On Mon, Nov 24, 2025 at 9:46 PM Crystal Wood <crwood@redhat.com> wrote:
>
> On Mon, 2025-11-17 at 15:41 -0300, Wander Lairson Costa wrote:
>
> >
> > diff --git a/tools/tracing/rtla/src/actions.c b/tools/tracing/rtla/src/actions.c
> > index efa17290926da..e23d4f1c5a592 100644
> > --- a/tools/tracing/rtla/src/actions.c
> > +++ b/tools/tracing/rtla/src/actions.c
> > @@ -199,12 +199,14 @@ actions_parse(struct actions *self, const char *trigger, const char *tracefn)
> >               /* Takes two arguments, num (signal) and pid */
> >               while (token != NULL) {
> >                       if (strlen(token) > 4 && strncmp(token, "num=", 4) == 0) {
> > -                             signal = atoi(token + 4);
> > +                             if(!strtoi(token + 4, &signal))
> > +                                     return -1;
>
> if (
>
> >                       } else if (strlen(token) > 4 && strncmp(token, "pid=", 4) == 0) {
> >                               if (strncmp(token + 4, "parent", 7) == 0)
> >                                       pid = -1;
> >                               else
> > -                                     pid = atoi(token + 4);
> > +                                     if (!strtoi(token + 4, &pid))
> > +                                             return -1;
>
> else if (
>
> Please run the patches through checkpatch.pl
>

Good catch, thanks.

> > @@ -959,3 +967,25 @@ int auto_house_keeping(cpu_set_t *monitored_cpus)
> >
> >       return 1;
> >  }
> > +
> > +/*
> > + * strtoi - convert string to integer with error checking
> > + *
> > + * Returns true on success, false if conversion fails or result is out of int range.
> > + */
> > +bool strtoi(const char *s, int *res)
>
> Could use __attribute__((__warn_unused_result__)) like kstrtoint().
>

Sure, I will do it in v2.

> BTW, it's pretty annoying that we need to reinvent the wheel on all this
> stuff just because it's userspace.  From some of the other tools it
> looks like we can at least include basic kernel headers like compiler.h;
> maybe we should have a tools/-wide common util area as well?  Even
> better if some of the code can be shared with the kernel itself.
>
> Not saying that should in any way be a blocker for these patches, just
> something to think about.
>

I thought the same thing some time ago.

>
> -Crystal
>