[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220211073919.GW614@gate.crashing.org>
Date: Fri, 11 Feb 2022 01:39:19 -0600
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Kees Cook <keescook@...omium.org>
Cc: Christophe Leroy <christophe.leroy@...roup.eu>,
linux-arch@...r.kernel.org, linux-ia64@...r.kernel.org,
linux-parisc@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Helge Deller <deller@....de>, linux-kernel@...r.kernel.org,
"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
linux-mm@...ck.org, Paul Mackerras <paulus@...ba.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v3 04/12] powerpc: Prepare func_desc_t for refactorisation
On Thu, Feb 10, 2022 at 04:54:52PM -0800, Kees Cook wrote:
> On Sun, Oct 17, 2021 at 02:38:17PM +0200, Christophe Leroy wrote:
(edited:)
> > +typedef struct {
> > + unsigned long addr;
> > +} func_desc_t;
> >
> > static func_desc_t func_desc(unsigned long addr)
> > {
> > + return (func_desc_t){addr};
> There's only 1 element in the struct, so okay, but it hurt my eyes a
> little. I would have been happier with:
>
> return (func_desc_t){ .addr = addr; };
>
> But of course that also looks bonkers because it starts with "return".
> So no matter what I do my eyes bug out. ;)
The usual way to avoid convoluted constructs is to name more factors.
So:
static func_desc_t func_desc(unsigned long addr)
{
func_desc_t desc = {};
desc.addr = addr;
return desc;
}
Segher
Powered by blists - more mailing lists