[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YRfzIuSjvt8Dc/YL@zeniv-ca.linux.org.uk>
Date: Sat, 14 Aug 2021 16:45:22 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Leon Romanovsky <leon@...nel.org>
Cc: Christophe JAILLET <christophe.jaillet@...adoo.fr>,
Dan Carpenter <dan.carpenter@...cle.com>,
Russell King - ARM Linux admin <linux@...linux.org.uk>,
Joe Perches <joe@...ches.com>,
Dwaipayan Ray <dwaipayanray1@...il.com>,
Andy Whitcroft <apw@...onical.com>,
Lukas Bulwahn <lukas.bulwahn@...il.com>,
linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
Julia Lawall <julia.lawall@...ia.fr>
Subject: Re: [PATCH] checkpatch: prefer = {} initializations to = {0}
On Sat, Aug 14, 2021 at 06:52:57PM +0300, Leon Romanovsky wrote:
> I reread gcc/c/c-typeck.c and at lest for GCC 10, I'm wrong about padding.
> Sorry about that.
>
> 8630 struct c_expr
> 8631 pop_init_level (location_t loc, int implicit,
> 8632 struct obstack *braced_init_obstack,
> 8633 location_t insert_before)
> ....
> 8692 switch (vec_safe_length (constructor_elements))
> 8693 {
> 8694 case 0:
> 8695 /* Initialization with { } counts as zeroinit. */
> 8696 constructor_zeroinit = 1;
> 8697 break;
> 8698 case 1:
> 8699 /* This might be zeroinit as well. */
> 8700 if (integer_zerop ((*constructor_elements)[0].value))
> 8701 constructor_zeroinit = 1;
> 8702 break;
> 8703 default:
> 8704 /* If the constructor has more than one element, it can't be { 0 }. */
> 8705 constructor_zeroinit = 0;
> 8706 break;
> 8707 }
FWIW, that reads more like "in those cases we might quietly turn the whole
thing into memset()" optimization, with no promise that it will be done
that way in future versions.
And considering the fun effects (infoleaks from stack or heap), it's not
something I'd rely upon - not without a much more explicit promise...
Powered by blists - more mailing lists