Re: [PATCH] checkpatch: prefer = {} initializations to = {0}

From: Al Viro <viro@zeniv.linux.org.uk>
To: Leon Romanovsky <leon@kernel.org>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	Joe Perches <joe@perches.com>,
	Dwaipayan Ray <dwaipayanray1@gmail.com>,
	Andy Whitcroft <apw@canonical.com>,
	Lukas Bulwahn <lukas.bulwahn@gmail.com>,
	linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
	Julia Lawall <julia.lawall@inria.fr>
Subject: Re: [PATCH] checkpatch: prefer = {} initializations to = {0}
Date: Sat, 14 Aug 2021 16:45:22 +0000	[thread overview]
Message-ID: <YRfzIuSjvt8Dc/YL@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <YRfm2RRYla7Nemsj@unreal>

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...