public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Qing Zhao <qing.zhao@oracle.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
	Martin Sebor <msebor@gmail.com>,
	gcc-patches Paul A Clarke via <gcc-patches@gcc.gnu.org>,
	kees Cook <keescook@chromium.org>
Subject: Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size
Date: Thu, 30 Jun 2022 19:03:39 +0200	[thread overview]
Message-ID: <Yr3Xa0HKoioXy3of@tucnak> (raw)
In-Reply-To: <F5485050-6E6C-44EE-B1F3-B463F32DAE8A@oracle.com>

On Thu, Jun 30, 2022 at 03:31:00PM +0000, Qing Zhao wrote:
> > No, that’s not true.  A FIELD_DELC is only shared for cv variants of a structure.
> 
> Sorry for my dump questions: 
> 
> 1. What do you mean by “cv variants” of a structure?

const/volatile qualified variants.  So

> 2. For the following example:
> 
> struct AX { int n; short ax[];};

struct AX, const struct AX, volatile const struct AX etc. types will share
the FIELD_DECLs.

> struct UX {struct AX b; int m;};
> 
> Are there two different FIELD_DECLs in the IR, one for AX.ax, the other one is for UX.b.ax?

No, there are just n and ax FIELD_DECLs with DECL_CONTEXT of struct AX and
b and m FIELD_DECLs with DECL_CONTEXT of struct UX.

But, what is important is that when some FIELD_DECL is last in some
structure and has array type, it doesn't mean it should have an
unconstrained length.
In the above case, when struct AX is is followed by some other member, it
acts as a strict short ax[0]; field (even when that is an exception), one
can tak address of &UX.b.ax[0], but can't dereference that, or &UX.b.ax[1].

I believe pedantically flexible array members in such cases don't
necessarily mean zero length array, could be longer, e.g. for the usual
x86_64 alignments
struct BX { long long n; short o; short ax[]; };
struct VX { struct BX b; int m; };
I think it acts as short ax[3]; because the padding at the end of struct BX
is so long that 3 short elements fit in there.
While if one uses
struct BX bx = { 1LL, 2, { 3, 4, 5, 6, 7, 8, 9, 10 } };
(a GNU extension), then it acts as short ax[11]; - the initializer is 8
elements and after short ax[8]; is padding for another 3 full elemenets.
And of course:
struct BX *p = malloc (offsetof (struct BX, ax) + n * sizeof (short));
means short ax[n].
Whether struct WX { struct BX b; };
struct WX *p = malloc (offsetof (struct WX, b.ax) + n * sizeof (short));
is pedantically acting as short ax[n]; is unclear to me, but we are
generally allowing that and people expect it.

Though, on the GCC side, I think we are only treating like flexible arrays
what is really at the end of structs, not followed by other members.

	Jakub


  reply	other threads:[~2022-06-30 17:03 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 [this message]
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
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=Yr3Xa0HKoioXy3of@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=keescook@chromium.org \
    --cc=msebor@gmail.com \
    --cc=qing.zhao@oracle.com \
    --cc=richard.guenther@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).