Received: by 2002:a05:6a10:c7d3:0:0:0:0 with SMTP id h19csp324014pxy; Sat, 14 Aug 2021 08:01:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxvUznaEjXOLATzMY50ibVS3SDa90NmpxHIJ4FxdywEzrMKrrkaGtt42mJCkLKqYpM0MRz X-Received: by 2002:a05:6638:d0a:: with SMTP id q10mr1262465jaj.88.1628953268176; Sat, 14 Aug 2021 08:01:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628953268; cv=none; d=google.com; s=arc-20160816; b=SdrV/vb3MnMOjl4bwBAlZP12HWgQIjbcJJnonQMlQTjJ95LPfqx31NuTi1ZbBhWU/0 +0ci+37ubizktkrbiLnOVa0wi770FYa9l9iqOWgZQahUa7j14sjeJmnEGoMQy+VDGjBg 2ZUR1/3rLCN5Ik+h/sZbySQ9gjKs3Fh3DaLXVbLKjd6S419FOHWFAIaYChBa48BgxB8j OAknyeh2veJK0sRFgZL0F5nk814891p1R7FXd9rj7qQMXmczFF0t2ZJqsL5gGLfwKA14 rKGFPwXMfjg0D9+zc7fDI+FsBce03d1AtLQDsYKTa42s7S48Ct1aOHj5vCTI7+u0UD7K CkOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=TJB2rOXxQ7hVif7f5Zw7dPPC1U+0xaqy8Xv2u2f8chc=; b=aDSUN31B8thIdYtUXWnPauLyCKPTaVzjXJ1bm6fR7fnxBZKZ2TK8n/ggNQYKOtcFBI zpedPIiRySGiqEaR+ssnhTjCsn2gjWqlE83GNvuxkrLC2mg1euvY1fflCm6eUsaEnoVF mlwHHv8ijrbqcNJfiitSJFtZFCppaMTOIR63cztqDskjEw0knVxHsRFN+lnTBQiENfaj r8Syi0PI+gORSu+FXcsuAHglHg/dytXNLlcw6k38hGDOT0cJovTk/5lmRUn7dM8SftVZ C/zQ55da4wZJgIqzujDm5QR/QX+0LGLsI8xx4tRhsER4GAZ7kkFzFL7Eoi8BsP+BAuJ9 2Qkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m4si5515380ili.30.2021.08.14.08.00.36; Sat, 14 Aug 2021 08:01:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238663AbhHNO5l (ORCPT + 99 others); Sat, 14 Aug 2021 10:57:41 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:36956 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235123AbhHNO5l (ORCPT ); Sat, 14 Aug 2021 10:57:41 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mEv1T-00BihQ-Gp; Sat, 14 Aug 2021 14:52:31 +0000 Date: Sat, 14 Aug 2021 14:52:31 +0000 From: Al Viro To: Christophe JAILLET Cc: Dan Carpenter , Russell King - ARM Linux admin , Leon Romanovsky , Joe Perches , Dwaipayan Ray , Andy Whitcroft , Lukas Bulwahn , linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Julia Lawall Subject: Re: [PATCH] checkpatch: prefer = {} initializations to = {0} Message-ID: References: <20210805104353.GD26417@kili> <1b94e688-a070-998a-3014-96bcbaed4cae@wanadoo.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b94e688-a070-998a-3014-96bcbaed4cae@wanadoo.fr> Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 14, 2021 at 03:59:22PM +0200, Christophe JAILLET wrote: > > +# prefer = {}; to = {0}; > > + if ($line =~ /= \{ *0 *\}/) { > > + WARN("ZERO_INITIALIZER", > > + "= {} is preferred over = {0}\n" . $herecurr); Sigh... "is preferred over" by whom? Use the active voice, would you? > [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. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf, but empty initializer-list is gccism anyway. Section 6.7.8 is the one to look through there. > Can someone provide some rational or compiler output that confirms that {} > and {0} are not the same? Easily: compare int x[] = {0}; and int x[] = {}; For more obscure example, int x = {0}; is valid, if pointless, but int x = {}; will be rejected even by gcc. Incidentally, do *NOT* assume that initializer will do anything with padding in a structure, no matter how you spell it. Neither {} nor {0} nor explicit initializer for each member of struct do anything to the padding. memset() does, but anything short of that leaves the padding contents unspecified.