Received: by 2002:a05:6a10:c7d3:0:0:0:0 with SMTP id h19csp489138pxy; Sat, 14 Aug 2021 13:25:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxItgooPz0F6VnAe9GHGzqTFOooUJTWpZrTOMFdjr3YyHkO7PH96he5OQz9dY+x1HYExKB4 X-Received: by 2002:a17:906:c091:: with SMTP id f17mr8739555ejz.134.1628972710637; Sat, 14 Aug 2021 13:25:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628972710; cv=none; d=google.com; s=arc-20160816; b=DAo1t3Jzuo0V6ReepU/EeLNhifef/7n+UB1kG3aBujnzW78yz890z3xsZeXPSaRjRB CclUaMwkjYrH5TkEqPFRgHZ9fD47HipZoRe5k/GLIeMrah0dgiPX/EP951/k9S+29Cz/ 31sukk4lSmeOCbGoF1gzDPuOaJk9ZJZsA3eyrgbE3k0226PyVX2lEhai6VdJYJXviMXy 3Q781P3LCmYYZOIBreb0yLRwe9yj+MgKtaj4ttGBz7zPnaqUhSP0ANiyHHnpagyR3c7R N1lmwB3zY7kteLsk70N7f8UThqHP1cqQvepuY8jVyRvuSg0947fy0Gz76emZ0ugWmu2h 2tDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=4WoA3SwtKBjBnOxricPre6zN2oLLnHULIedI7QWbXq8=; b=Y5vFRcU6xTzmzAwOVAoAmlea+WsE+85w+fLPoST7eaoyxBVWx9N5wVBWey/7aUsAde 09B/FlUnHBOOGynmo7VF/Wwk43vD9Cb/sZJrJPkJZ8I0FDRS4vGboqwAKl4nNq0NSLm3 yIuQVtifqNbM1W/X5bEMZW+KsSffeI+hrXqQCfCN1Tnbxl3WmQaPVpCcBIhWtBua3gwP wxJmVqo2wHECjW6Y6+1woxiyM7XxGmx9sYY/hHii0QGWtbkGO+JAoPPMvIT9EdWW0uBD YaqAu/Hn9oVwxcA0C8iZjnBl/SV/zo4GWgtcS6YwzDhfFEI2c/j5pQO6hJsgPCvj/+TL XNpQ== 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 cw26si5475755edb.32.2021.08.14.13.24.48; Sat, 14 Aug 2021 13:25:10 -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 S232919AbhHNUVD (ORCPT + 99 others); Sat, 14 Aug 2021 16:21:03 -0400 Received: from smtp11.smtpout.orange.fr ([80.12.242.133]:27917 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231745AbhHNUVD (ORCPT ); Sat, 14 Aug 2021 16:21:03 -0400 Received: from [192.168.1.18] ([90.126.253.178]) by mwinf5d21 with ME id hYLR250073riaq203YLSxi; Sat, 14 Aug 2021 22:20:32 +0200 X-ME-Helo: [192.168.1.18] X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Sat, 14 Aug 2021 22:20:32 +0200 X-ME-IP: 90.126.253.178 Subject: Re: [PATCH] checkpatch: prefer = {} initializations to = {0} To: Al Viro 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 References: <20210805104353.GD26417@kili> <1b94e688-a070-998a-3014-96bcbaed4cae@wanadoo.fr> From: Christophe JAILLET Message-ID: Date: Sat, 14 Aug 2021 22:20:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 14/08/2021 à 16:52, Al Viro a écrit : > 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. > Thanks for the explanations and exemples. IIUC, code like [1] may leak some data (1 char) because of the layout of 'struct atyclk' and we have the erroneous feeling that it is fully initialized, because of the "{ 0 }". Correct? CJ [1]: https://elixir.bootlin.com/linux/v5.14-rc5/source/drivers/video/fbdev/aty/atyfb_base.c#L1859