[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgSovEz3gy56q0bhOMVt9Rx5ooq97KmY=XX37_JdE+4pQ@mail.gmail.com>
Date: Fri, 21 Dec 2018 14:57:13 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Namhyung Kim <namhyung@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Joe Perches <joe@...ches.com>,
Tom Zanussi <zanussi@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [for-next][PATCH 23/24] string.h: Add strncmp_prefix() helper macro
On Fri, Dec 21, 2018 at 2:48 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> > Your patch actually had them, but in the body of your email you did
> >
> > > #define have_prefix(str, prefix) ({ \
> > > const char *__pfx = (const char *)prefix; \
> >
> > which is just completely wrong.
> >
> > Considering your _old_ patch had the exact same bug, I really think
> > you need to start internalizing the whole "macro arguments *have* to
> > be properly protected" thing.
>
> Well, there's less with assignments that can go wrong than with other
> code. That is, there's little that can happen with "int x = arg;" where
> arg is the macro paramater to cause something really nasty.
What's wrong, Steven?
The assignment is entirely irrelevant.
The problem is the cast.
A type cast has a very high priority, and so if you do
(const char *)prefix
it breaks completely if you might have something like"a+6" as the argument.
Think about what if "a" is of type "unsigned long", for example?
Linus
Powered by blists - more mailing lists