Received: by 2002:a05:6a10:c7d3:0:0:0:0 with SMTP id h19csp385416pxy; Sat, 14 Aug 2021 09:46:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyAlN3I+bMpplc8Cm9aa0BmL52GLa6xnjpKjzAFxCEdylaoNHKAoQoIO6kw5Nl7vVlfpFzh X-Received: by 2002:a92:1e0b:: with SMTP id e11mr5873736ile.35.1628959592820; Sat, 14 Aug 2021 09:46:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628959592; cv=none; d=google.com; s=arc-20160816; b=Q/v24AmJmQ+upA9DRHaF61m2wu0wFbyAsaUqjM6j7VygqPjjuWVtGgOC2CdQtoIdQD Dk4lQ3oQ1X6sgb/5naMatmEAeVczDv1MBxwAJK4EMVLNZqhCUwH/CfcgMwcMmsqQlmZt UBN6f4qyLEImxh7962caojSNThy4NcdmplF65Lrf3M7iZlIynz1q/rHsodv4otaThiky RDvfiMmhRP70err1UAzbRXlfgrRCDqhTcw7b1jTQya2cWkYjgeUCMpKwa+g4CQW3+8BA XmtcpdErYiMGVUwj49X9NOHfneygdJSv5dkSq1dD9lpvioiP380OElRfQbQfg/tlUaO1 o3RQ== 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=c6Ze33Wa7Zrn7XGYtCBUCczyBQa9NDXTrP9SjgY45+U=; b=xlPKftfXCKy7liwIz6cxQUfjA67kj8AuFrC9gKaKnVwzj0RxlzUfwaQQg2JDdLMU+k nv2gukR1y+hJp0r1U9ufU43tn9LPT+DF3S84mjYz4JUukEdQ7zfctcdleoo05yaFaM+g NOO3oWPw59Nm+uuvDIgwzyQkrLCmbYsaugsoxkChA1aPVtgEUTnSD66ElfTlmyV7C2Pz 7CDMpni5IHMKNSIpKIExtpspsuIyzXLqMTQWAUmSxL1AMer5JTzwScpZbKInk16q51bk L57BjWaGx1wAH6viXaJ8FV2NNblaQqrVxVGDNllvEVa4t4o5wGrlqfg1Mixjf5S2xhux 1gHQ== 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 j23si5253786jam.32.2021.08.14.09.46.19; Sat, 14 Aug 2021 09:46:32 -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 S236394AbhHNQqB (ORCPT + 99 others); Sat, 14 Aug 2021 12:46:01 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:38440 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233116AbhHNQqA (ORCPT ); Sat, 14 Aug 2021 12:46:00 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mEwmg-00Bk4d-4g; Sat, 14 Aug 2021 16:45:22 +0000 Date: Sat, 14 Aug 2021 16:45:22 +0000 From: Al Viro To: Leon Romanovsky Cc: Christophe JAILLET , Dan Carpenter , Russell King - ARM Linux admin , 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: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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...