public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Qing Zhao <qing.zhao@oracle.com>
To: Siddhesh Poyarekar <siddhesh@gotplt.org>,
	kees Cook <keescook@chromium.org>,
	Richard Biener <rguenther@suse.de>
Cc: "joseph@codesourcery.com" <joseph@codesourcery.com>,
	gcc Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [V2][PATCH 1/1] Add a new warning option -Wstrict-flex-arrays.
Date: Thu, 1 Dec 2022 22:27:41 +0000	[thread overview]
Message-ID: <7F963B56-040D-4384-B51B-3A63A3E38249@oracle.com> (raw)
In-Reply-To: <898dfeed-f392-fb86-7fbd-f99d335c7a64@gotplt.org>

Hi, Sid,

Thanks a lot for the input.

After more thinking based on your and Kees’ comments, I have the following thought:

1. -fstrict-flex-arrays=level should control both GCC code gen and warnings consistently;
2. We need warnings specifically for -fstrict-flex-arrays=level to report any misuse of flexible 
     array corresponding to the “level” to gradually encourage language standard.

So, based on the above two, I think what I did in this current patch is correct:

1.  We eliminate the control from -Warray-bounds=level on treating flex arrays, 
     now only "-fstrict-flex-arrasy=level" controls how the warning treating the flex arrays.
2.  We add a separate new warning -Wstrict-flex-arrays to report any misuse corresponding to
     the different level of -fstrict-flex-arrays.

Although we can certainly merge these new warnings into -Warray-bounds, however, as Sid mentioned,
-Warray-bounds does issue a lot more warnings than just flexible arrays misuse. I think it’s necessary 
To provide a seperate warning to only issue flexible array misuse.

Let me know if you have any more comments on this.

thanks.

Qing



> On Dec 1, 2022, at 2:45 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
> On 2022-12-01 11:42, Kees Cook wrote:
>> On Wed, Nov 30, 2022 at 02:25:56PM +0000, Qing Zhao wrote:
>>> '-Wstrict-flex-arrays'
>>>      Warn about inproper usages of flexible array members according to
>>>      the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
>>>      the trailing array field of a structure if it's available,
>>>      otherwise according to the LEVEL of the option
>>>      '-fstrict-flex-arrays=LEVEL'.
>>> 
>>>      This option is effective only when LEVEL is bigger than 0.
>>>      Otherwise, it will be ignored with a warning.
>>> 
>>>      when LEVEL=1, warnings will be issued for a trailing array
>>>      reference of a structure that have 2 or more elements if the
>>>      trailing array is referenced as a flexible array member.
>>> 
>>>      when LEVEL=2, in addition to LEVEL=1, additional warnings will be
>>>      issued for a trailing one-element array reference of a structure if
>>>      the array is referenced as a flexible array member.
>>> 
>>>      when LEVEL=3, in addition to LEVEL=2, additional warnings will be
>>>      issued for a trailing zero-length array reference of a structure if
>>>      the array is referenced as a flexible array member.
>>> 
>>> At the same time, -Warray-bounds is updated:
>> Why is there both -Wstrict-flex-arrays and -Warray-bounds? I thought
>> only the latter was going to exist?
> 
> Oh my understanding of the consensus was to move flex array related diagnosis from -Warray-bounds to -Wstring-flex-arrays as Qing has done. If only the former exists then instead of removing the flex array related statement in the documentation as Richard suggested, we need to enhance it to say that behaviour of -Warray-bounds will depend on -fstrict-flex-arrays.
> 
> -Warray-bounds does diagnosis beyond just flexible arrays, in case that's the confusion.
> 
> Sid


  reply	other threads:[~2022-12-01 22:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-30 14:25 [V2][PATCH 0/1]Add " Qing Zhao
2022-11-30 14:25 ` [V2][PATCH 1/1] Add " Qing Zhao
2022-12-01 16:42   ` Kees Cook
2022-12-01 17:04     ` Qing Zhao
2022-12-01 17:18       ` Kees Cook
2022-12-01 17:48         ` Qing Zhao
2022-12-01 19:45     ` Siddhesh Poyarekar
2022-12-01 22:27       ` Qing Zhao [this message]
2022-12-01 23:19         ` Kees Cook
2022-12-01 23:53           ` Siddhesh Poyarekar
2022-12-02  7:16       ` Richard Biener
2022-12-02  7:20         ` Richard Biener
2022-12-02 14:43           ` Qing Zhao
2022-12-05 15:16             ` Richard Biener
2022-12-05 15:20               ` Qing Zhao
2022-12-02 14:40         ` Qing Zhao
2022-12-06 16:14 [V3][PATCH 0/2]Update -Warray-bounds with -fstrict-flex-arrays Qing Zhao
2022-12-06 16:14 ` [V2][PATCH 1/1] Add a new warning option -Wstrict-flex-arrays Qing Zhao
2022-12-06 16:16   ` Qing Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7F963B56-040D-4384-B51B-3A63A3E38249@oracle.com \
    --to=qing.zhao@oracle.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=keescook@chromium.org \
    --cc=rguenther@suse.de \
    --cc=siddhesh@gotplt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).