From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id BAD9038493D9; Thu, 24 Nov 2022 06:45:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BAD9038493D9 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 2C59A2188B; Thu, 24 Nov 2022 06:45:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1669272314; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sWFXuT4cGaqZneToCv5vzuBZCZVYYcy2drUZwAwioHU=; b=XvlMd1b0sR6Bj+v5thVOZZjmlWESdwCNE1S4Ef6jRvTrO690RcFoQLYL0mPWYlJP2u6VNQ B21lBbYU5EPoztV5wWlUfzA8gzbblWYiGu6XICKYGRvrNspuu8c6qbwCGNh/wCfQtqH9Kr M/ok1doZthcoT6nJdmaDPoOjk+hTjZ0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1669272314; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sWFXuT4cGaqZneToCv5vzuBZCZVYYcy2drUZwAwioHU=; b=WjXiwmdTXbIG7oYoxDSsPs0yV+jjMcJR8QDVCldQfyS2Usw7SIp4HMurEVoR4A/c4Lnc49 r87fMPbWPDfMhOBA== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 000232C141; Thu, 24 Nov 2022 06:45:13 +0000 (UTC) Date: Thu, 24 Nov 2022 06:45:13 +0000 (UTC) From: Richard Biener To: Kees Cook cc: Qing Zhao , "joseph@codesourcery.com" , gcc Patches , "siddhesh@gcc.gnu.org" Subject: Re: [PATCH 2/2] Add a new warning option -Wstrict-flex-arrays. In-Reply-To: <202211220916.DCA9DE509@keescook> Message-ID: References: <20221108145113.955321-1-qing.zhao@oracle.com> <20221108145113.955321-3-qing.zhao@oracle.com> <202211180829.4F995ED2@keescook> <2AA33592-14D4-4E89-91F1-221F635117F1@oracle.com> <9AD3179B-F877-437E-9052-CB01AD55E684@oracle.com> <202211220916.DCA9DE509@keescook> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 22 Nov 2022, Kees Cook wrote: > On Tue, Nov 22, 2022 at 03:02:04PM +0000, Qing Zhao wrote: > > > > > > > On Nov 22, 2022, at 9:10 AM, Qing Zhao via Gcc-patches wrote: > > > > > > > > > > > >> On Nov 22, 2022, at 3:16 AM, Richard Biener wrote: > > >> > > >> On Mon, 21 Nov 2022, Qing Zhao wrote: > > >> > > >>> > > >>> > > >>>> On Nov 18, 2022, at 11:31 AM, Kees Cook wrote: > > >>>> > > >>>> On Fri, Nov 18, 2022 at 03:19:07PM +0000, Qing Zhao wrote: > > >>>>> Hi, Richard, > > >>>>> > > >>>>> Honestly, it?s very hard for me to decide what?s the best way to handle the interaction > > >>>>> between -fstrict-flex-array=M and -Warray-bounds=N. > > >>>>> > > >>>>> Ideally, -fstrict-flex-array=M should completely control the behavior of -Warray-bounds. > > >>>>> If possible, I prefer this solution. > > >>>>> > > >>>>> However, -Warray-bounds is included in -Wall, and has been used extensively for a long time. > > >>>>> It?s not safe to change its default behavior. > > >>>> > > >>>> I prefer that -fstrict-flex-arrays controls -Warray-bounds. That > > >>>> it is in -Wall is _good_ for this reason. :) No one is going to add > > >>>> -fstrict-flex-arrays (at any level) without understanding what it does > > >>>> and wanting those effects on -Warray-bounds. > > >>> > > >>> > > >>> The major difficulties to let -fstrict-flex-arrays controlling -Warray-bounds was discussed in the following threads: > > >>> > > >>> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604133.html > > >>> > > >>> Please take a look at the discussion and let me know your opinion. > > >> > > >> My opinion is now, after re-considering and with seeing your new > > >> patch, that -Warray-bounds=2 should be changed to only add > > >> "the intermediate results of pointer arithmetic that may yield out of > > >> bounds values" and that what it considers a flex array should now > > >> be controlled by -fstrict-flex-arrays only. > > >> > > >> That is, I think, the only thing that's not confusing to users even > > >> if that implies a change from previous behavior that we should > > >> document by clarifying the -Warray-bounds documentation as well as > > >> by adding an entry to the Caveats section of gcc-13/changes.html > > >> > > >> That also means that =2 will get _less_ warnings with GCC 13 when > > >> the user doesn't use -fstrict-flex-arrays as well. > > > > > > Okay. So, this is for -Warray-bounds=2. > > > > > > For -Warray-bounds=1 -fstrict-flex-array=N, if N > 1, should -fstrict-flex-array=N control -Warray-bounds=1? > > > > More thinking on this. (I might misunderstand a little bit in the previous email) > > > > If I understand correctly now, what you proposed was: > > > > 1. The level of -Warray-bounds will NOT control how a trailing array is considered as a flex array member anymore. > > 2. Only the level of -fstrict-flex-arrays will control this; > > 3. Keep the current default behavior of -Warray-bounds on treating trailing arrays as flex array member (treating all [0],[1], and [] as flexible array members). > > 4. Updating the documentation for -Warray-bounds by clarifying this change, and also as an entry to the Caveats section on such change on -Warray-bounds. > > > > If the above is correct, Yes, I like this change. Both the user interface and the internal implementation will be simplified and cleaner. > > > > Let me know if you see any issue with my above understanding. > > > > Thanks a lot. > > FWIW, this matches what I think makes the most sense too. Yes, I think that makes most sense. As said for -Warray-bounds=2 this will change behavior but since that's not the default that should be fine if documented. Thanks, Richard.