From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 796FE3858D20; Tue, 22 Nov 2022 08:16:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 796FE3858D20 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-out2.suse.de (Postfix) with ESMTP id 1EF721F86B; Tue, 22 Nov 2022 08:16:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1669105017; 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=+xUkOBkV9sG3i8IpjhE1aLilpjEkJZ7PWj7cGySlYME=; b=dbZ6LSH7Ci2So8+PMS9PTN78pzCRZKEekImXgVHF5srssdSLUXSdxbqqx96jJO5g1F5t+t zDYHnF6v6Pgc15wpJsgQzFKG7bMmZf8sZvaavCWeqYzReqQqkIQklmmkmzF7cKsmCybAIn aMmF9amUn2ffMFGQJIHudIUUe3frdxI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1669105017; 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=+xUkOBkV9sG3i8IpjhE1aLilpjEkJZ7PWj7cGySlYME=; b=QAyZsvzBBbVLXE8tqov85A+tUvk4H1Qy2ccHg6NpYcrQCZwWmJoBvctZfEUiCUNiE8nNiv NYU7QE2ijOvK4aCg== 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 087052C142; Tue, 22 Nov 2022 08:16:56 +0000 (UTC) Date: Tue, 22 Nov 2022 08:16:56 +0000 (UTC) From: Richard Biener To: Qing Zhao cc: Kees Cook , "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: <2AA33592-14D4-4E89-91F1-221F635117F1@oracle.com> 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> 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 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. Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)