[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200901122158.GX8299@kadam>
Date: Tue, 1 Sep 2020 15:21:58 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: "antoni.przybylik@...pl" <antoni.przybylik@...pl>
Cc: Greg KH <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org,
devel@...verdev.osuosl.org
Subject: Re: Fwd: Re: [PATCH] staging: gdm724x: gdm_tty: corrected macro by
adding brackets
On Tue, Sep 01, 2020 at 02:06:23PM +0200, antoni.przybylik@...pl wrote:
> On 01.09.2020 13:08, Greg KH wrote:
> > On Tue, Sep 01, 2020 at 12:43:11PM +0200, antoniprzybylik wrote:
> > > Such macros are dangerous. Consider following example:
> > > #define GDM_TTY_READY(gdm) (gdm && gdm->tty_dev && gdm->port.count)
> > > GDM_TTY_READY(a + b)
> > > This macro will be expanded in such a way:
> > > (a + b && a + b->tty_dev && a + b->port.count)
> > > And it will lead to errors.
> > This is for a pointer, no one would ever do that :)
>
> Nobody adds a pointer to a pointer, but it's common to add to it some value
> like that:
>
> GDM_TTY_READY(myptr + 0x1000)
That won't compile at all, because it expands to "gdm + 0x1000->tty_dev".
>
> > But, if you really worry about this, turn it into an inline function,
> > that way you get the proper typedef safety, which is what something like
> > this should really be, not a macro.
>
> How to do it? Do I need to send another patch?
Yeah. If you want. Or you could just find something else to patch.
Probably just find a different bug and fix that instead... If at first
you don't succeed, there are tons of other stuff to work on and maybe
you will succeed there. ;)
regards,
dan carpenter
Powered by blists - more mailing lists