[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YRfm2RRYla7Nemsj@unreal>
Date: Sat, 14 Aug 2021 18:52:57 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Al Viro <viro@...iv.linux.org.uk>
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 02:57:06PM +0000, Al Viro wrote:
> On Sat, Aug 14, 2021 at 05:38:27PM +0300, Leon Romanovsky wrote:
>
> > There are number of reasons why you didn't notice any difference.
> > 1. {} is GCC extension
> > 2. {} was adopted in latest C standards, so need to check which one GCC 10
> > is using by default.
> > 3. Main difference will be in padding - {0} will set to zero fields but
> > won't touch padding, while {} will zero everything.
>
> References on (3), please?
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 }
8708
Powered by blists - more mailing lists