public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Qing Zhao <qing.zhao@oracle.com>
To: Jakub Jelinek <jakub@redhat.com>,
	"joseph@codesourcery.com" <joseph@codesourcery.com>
Cc: gcc-patches Paul A Clarke via <gcc-patches@gcc.gnu.org>,
	kees Cook <keescook@chromium.org>,
	Martin Sebor <msebor@gmail.com>
Subject: Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size
Date: Wed, 29 Jun 2022 20:45:10 +0000	[thread overview]
Message-ID: <A3F4ED0D-4F0E-4A97-BDDA-F7FEBEA44B92@oracle.com> (raw)
In-Reply-To: <YrsvsoTparTlXUq2@tucnak>

Hi, Jakub and Joseph:


> On Jun 28, 2022, at 12:43 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> On Tue, Jun 28, 2022 at 03:59:22PM +0000, Qing Zhao via Gcc-patches wrote:
>>> On Jun 28, 2022, at 11:08 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>>> 
>>> On Tue, Jun 28, 2022 at 03:03:12PM +0000, Qing Zhao wrote:
>>>> 2. Then replace all “array_at_struct_end_p” with using DECL_NOT_FLEXARRAY in GCC, adding new testing cases
>>> 
>>> No, IMHO array_at_struct_end_p should stay as is, just test this extra flag
>>> too.
>> 
>> Could you please explain why we still need “array_at_struct_end_p” after we have the DECL_NOT_FLEXARRAY flag in FIELD_DECL?
> 
> Because the flag just tells whether some array shouldn't be treated as (poor man's)
> flexible array member.  We still need to find out if some FIELD_DECL is to
> be treated like a flexible array member, which is a minority of
> COMPONENT_REFs.
> struct S { int a; char b[0]; int c; } s;
> struct T { int d; char e[]; };
> struct U { int f; struct T g; int h; } u;
> Neither s.b nor u.g.e is to be treated like flexible array member,
> no matter what -fstrict-flex-array= option is used.

I studied the above a little bit today with the following small testing cases:
[opc@qinzhao-ol8u3-x86 trailing_array]$ cat t1.c
struct AX
{
  int n;
  short ax[];
  int m;
};

void warn_ax_local (struct AX *p)
{
  p->ax[2] = 0;   
}
[opc@qinzhao-ol8u3-x86 trailing_array]$ /home/opc/Install/latest/bin/gcc -O2 -Wall  t1.c -S
t4.c:4:9: error: flexible array member not at end of struct
    4 |   short ax[];
      |         ^~

Looks like that it’s an error when the flexible array member is not at end of a struct.

However, for

[opc@qinzhao-ol8u3-x86 trailing_array]$ cat t2.c
struct AX
{
  int n;
  short ax[];
};

struct UX
{
  struct AX b;
  int m;
};

void warn_ax_local (struct AX *p, struct UX *q)
{
  p->ax[2] = 0;   
  q->b.ax[2] = 0;
}

[opc@qinzhao-ol8u3-x86 trailing_array]$  /home/opc/Install/latest/bin/gcc -O2 -Wall  t2.c -S
[opc@qinzhao-ol8u3-x86 trailing_array]$ 


My impression is:

C frontend is able to check whether the field is at the end of the structure and report error when it detect a flexible array member is not at the end of struct.

My question is:

1. Is the usage of flexible array member in struct UX of t2.c correct?
2. Why it’s correct?
3. If not correct, is this a bug in FE?

Thanks.

Qing



  parent reply	other threads:[~2022-06-29 20:45 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 14:19 Qing Zhao
2022-06-28  7:16 ` Richard Biener
2022-06-28 15:03   ` Qing Zhao
2022-06-28 15:08     ` Jakub Jelinek
2022-06-28 15:59       ` Qing Zhao
2022-06-28 16:43         ` Jakub Jelinek
2022-06-28 18:15           ` Qing Zhao
2022-06-28 18:22             ` Jakub Jelinek
2022-06-28 18:29               ` Qing Zhao
2022-06-28 18:49                 ` Jakub Jelinek
2022-06-28 19:01                   ` Qing Zhao
2022-06-29 21:14                     ` Martin Sebor
2022-06-30 14:07                       ` Qing Zhao
2022-06-30 14:24                         ` Richard Biener
2022-06-30 15:31                           ` Qing Zhao
2022-06-30 17:03                             ` Jakub Jelinek
2022-06-30 19:30                               ` Qing Zhao
2022-07-01  6:49                                 ` Richard Biener
2022-07-01 12:55                                   ` Qing Zhao
2022-07-01 12:58                                     ` Richard Biener
2022-07-01 13:40                                       ` Qing Zhao
2022-07-01 12:59                                     ` Jakub Jelinek
2022-07-01 14:01                                       ` Qing Zhao
2022-07-01 15:32                                         ` Martin Sebor
2022-07-04  6:49                                           ` Richard Biener
2022-07-06 14:20                                             ` Qing Zhao
2022-07-07  8:02                                               ` Richard Biener
2022-07-07 13:33                                                 ` Qing Zhao
2022-06-29 20:45           ` Qing Zhao [this message]
2022-06-28 16:21   ` Martin Sebor

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=A3F4ED0D-4F0E-4A97-BDDA-F7FEBEA44B92@oracle.com \
    --to=qing.zhao@oracle.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=keescook@chromium.org \
    --cc=msebor@gmail.com \
    /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).