linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: 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 17:38:27 +0300	[thread overview]
Message-ID: <YRfVYxQ126AOuexl@unreal> (raw)
In-Reply-To: <1b94e688-a070-998a-3014-96bcbaed4cae@wanadoo.fr>

On Sat, Aug 14, 2021 at 03:59:22PM +0200, Christophe JAILLET wrote:
> Hi all,
> 
> Le 05/08/2021 à 12:43, Dan Carpenter a écrit :
> > The "= {};" style empty struct initializer is preferred over = {0}.
> > It avoids the situation where the first struct member is a pointer and
> > that generates a Sparse warning about assigning using zero instead of
> > NULL.  Also it's just nicer to look at.
> > 
> > Some people complain that {} is less portable but the kernel has
> > different portability requirements from userspace so this is not a
> > issue that we care about.
> > 
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > ---
> >   scripts/checkpatch.pl | 6 ++++++
> >   1 file changed, 6 insertions(+)
> > 
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 461d4221e4a4..32c8a0ca6fd0 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -4029,6 +4029,12 @@ sub process {
> >   			     "Using $1 is unnecessary\n" . $herecurr);
> >   		}
> > +# prefer = {}; to = {0};
> > +		if ($line =~ /= \{ *0 *\}/) {
> > +			WARN("ZERO_INITIALIZER",
> > +			     "= {} is preferred over = {0}\n" . $herecurr);
> > +		}
> > +
> >   # Check for potential 'bare' types
> >   		my ($stat, $cond, $line_nr_next, $remain_next, $off_next,
> >   		    $realline_next);
> > 
> 
> [1] and [2] state that {} and {0} don't have the same effect. So if correct,
> this is not only a matter of style.
> 
> When testing with gcc 10.3.0, I arrived at the conclusion that both {} and
> {0} HAVE the same behavior (i.e the whole structure and included structures
> are completely zeroed) and I don't have a C standard to check what the rules
> are.
> gcc online doc didn't help me either.
> 
> To test, I wrote a trivial C program, compiled it with gcc -S and looked at
> the assembly files.
> 
> 
> Maybe, if it is an undefined behavior, other compilers behave differently
> than gcc.
> 
> 
> However, the 2 persons listed bellow have a much better Linux and C
> background than me. So it is likely that my testings were too naive.

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.

> 
> 
> Can someone provide some rational or compiler output that confirms that {}
> and {0} are not the same?
> 
> Because if confirmed, I guess that there is some clean-up work to do all
> over the code, not only to please Sparse!
> 
> 
> Thanks in advance.
> CJ
> 
> 
> 
> [1]: Russell King - https://lore.kernel.org/netdev/YRFGxxkNyJDxoGWu@shredder/T/#efe1b6c7862b7ca9588c2734f04be5ef94e03d446
> 
> [2]: Leon Romanovsky - https://lore.kernel.org/netdev/YRFGxxkNyJDxoGWu@shredder/T/#efe1b6c7862b7ca9588c2734f04be5ef94e03d446

  parent reply	other threads:[~2021-08-14 14:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 10:43 [PATCH] checkpatch: prefer = {} initializations to = {0} Dan Carpenter
2021-08-05 12:27 ` Joe Perches
2021-08-05 18:04   ` Joe Perches
2021-08-05 18:17     ` Julia Lawall
2021-08-05 18:28       ` Joe Perches
2021-08-05 18:44         ` Julia Lawall
     [not found] ` <20210814135922.gIT6AWiUertQCb4-mO0DlLP6vG6pje2EMBqDKlqmBVM@z>
2021-08-14 13:59   ` Christophe JAILLET
2021-08-14 14:05     ` Marion & Christophe JAILLET
2021-08-14 14:38     ` Leon Romanovsky [this message]
2021-08-14 14:57       ` Al Viro
2021-08-14 15:52         ` Leon Romanovsky
2021-08-14 16:45           ` Al Viro
2021-08-14 14:44     ` Russell King (Oracle)
2021-08-14 14:52     ` Al Viro
2021-08-14 20:20       ` Christophe JAILLET
2021-08-16  6:55       ` Dan Carpenter
2021-08-16  7:23         ` Russell King (Oracle)
2021-08-16 19:05           ` Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YRfVYxQ126AOuexl@unreal \
    --to=leon@kernel.org \
    --cc=apw@canonical.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=dan.carpenter@oracle.com \
    --cc=dwaipayanray1@gmail.com \
    --cc=joe@perches.com \
    --cc=julia.lawall@inria.fr \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lukas.bulwahn@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).