lkml.org 
[lkml]   [2021]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Fix application of sizeof to pointer
Date
On Mon, 2021-10-11 at 23:06 -0400, Steven Rostedt wrote:
> On Tue, 12 Oct 2021 10:54:24 +0800
> davidcomponentone@gmail.com wrote:
>
> > From: David Yang <davidcomponentone@gmail.com>
> >
> > The coccinelle check report:
> > "./tools/tracing/latency/latency-collector.c:1541:10-16:
> > ERROR: application of sizeof to pointer"
> > Using the "strlen" to fix it.
> >
> > Reported-by: Zeal Robot <zealci@zte.com.cn>
> > Signed-off-by: David Yang <davidcomponentone@gmail.com>
> > ---
> > tools/tracing/latency/latency-collector.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/tracing/latency/latency-collector.c
> > b/tools/tracing/latency/latency-collector.c
> > index 3a2e6bb781a8..b131007e6c70 100644
> > --- a/tools/tracing/latency/latency-collector.c
> > +++ b/tools/tracing/latency/latency-collector.c
> > @@ -1538,7 +1538,7 @@ static void tracing_loop(void)
> > mutex_lock(&print_mtx);
> > check_signals();
> > write_or_die(fd_stdout, queue_full_warning,
> > - sizeof(queue_full_warning));
> > + strlen(queue_full_warning) + 1);
>
> Really, the +1, although would match if queue_full_warning was an
> array, but in this use case, there's no reason to pass the nul
> character to the write.

I agree that the +1 should not be there because the null character would end up
in the output; write will not ignore it. It could be confusing if the output
would be be processed by another program.

best regards,

Viktor

>
> -- Steve
>
>
> > mutex_unlock(&print_mtx);
> > }
> > modified--;
\
 
 \ /
  Last update: 2021-10-12 13:14    [W:0.146 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site