public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Sebastian Huber <sebastian.huber@embedded-brains.de>
Cc: Qing Zhao <qing.zhao@oracle.com>,
	gcc-patches@gcc.gnu.org,  joseph@codesourcery.com
Subject: Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
Date: Mon, 6 May 2024 09:08:32 +0200 (CEST)	[thread overview]
Message-ID: <08858rs4-6qn8-227n-383q-o0ss0p433s07@fhfr.qr> (raw)
In-Reply-To: <e31c59e9-2a1d-4013-a9ea-5d03c8584cb5@embedded-brains.de>

On Sat, 4 May 2024, Sebastian Huber wrote:

> On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
> > Hi,
> > 
> > This is the 2nd version of the patch.
> > Comparing to the 1st version, the only change is to address Richard's
> > comment on refering a warning option for diagnosing deprecated behavior.
> > 
> > 
> > Okay for committing?
> > 
> > thanks.
> > 
> > Qing
> > 
> > ======
> > 
> > *htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C
> > extension about flexible array members.
> > ---
> >   htdocs/gcc-14/changes.html | 13 ++++++++++++-
> >   1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> > index dad1ba53..eae25f1a 100644
> > --- a/htdocs/gcc-14/changes.html
> > +++ b/htdocs/gcc-14/changes.html
> > @@ -30,7 +30,18 @@ a work-in-progress.</p>
> >   <!-- ..................................................................
> >   -->
> >   <h2>Caveats</h2>
> >   <ul>
> > -  <li>...</li>
> > +  <li><strong>C:</strong>
> > +      Support for the GCC extension, a structure containing a C99 flexible
> > array
> > +      member, or a union containing such a structure, is not the last field
> > of
> > +      another structure, is deprecated. Refer to
> > +      <a href="https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html">
> > +      Zero Length Arrays</a>.
> > +      Any code relying on this extension should be modifed to ensure that
> > +      C99 flexible array members only end up at the ends of structures.
> > +      Please use the warning option
> > +      <a
> > href="https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end"><code>-Wflex-array-member-not-at-end</code></a>
> > to
> > +      identify all such cases in the source code and modify them.
> > +  </li>
> >   </ul>
> 
> I have a question with respect to the static initialization of flexible array
> members. According to the documentation this is supported by GCC:
> 
> https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> 
> "GCC allows static initialization of flexible array members. This is
> equivalent to defining a new structure containing the original structure
> followed by an array of sufficient size to contain the data. E.g. in the
> following, f1 is constructed as if it were declared like f2.
> 
> struct f1 {
>   int x; int y[];
> } f1 = { 1, { 2, 3, 4 } };
> 
> struct f2 {
>   struct f1 f1; int data[3];
> } f2 = { { 1 }, { 2, 3, 4 } };
> "
> 
> However, when I compile this code, I get a warning like this:
> 
> flex-array.c:6:13: warning: structure containing a flexible array member is
> not at the end of another structure [-Wflex-array-member-not-at-end]
>     6 |   struct f1 f1; int data[3];
>       |
> 
> In general, I agree that flexible array members should be at the end, however
> the support for static initialization is quite important from my point of view
> especially for applications for embedded systems. Here, dynamic allocations
> may not be allowed or feasible.

I do not get a diagnostic for this on trunk?  And I agree there shouldn't
be any.

Richard.

  reply	other threads:[~2024-05-06  7:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07 14:22 Qing Zhao
2023-08-08  7:55 ` Richard Biener
2023-09-25 18:24 ` Improve -Wflex-array-member-not-at-end changes.html wording |Plus: and warning bug? (was: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.) Tobias Burnus
2023-09-26  6:49   ` Richard Biener
2023-09-26  7:26     ` Improve -Wflex-array-member-not-at-end changes.html wording |Plus: and warning bug? Tobias Burnus
2023-10-02  3:58   ` Improve -Wflex-array-member-not-at-end changes.html wording |Plus: and warning bug? (was: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.) Qing Zhao
2023-10-19 20:49   ` Qing Zhao
2023-10-19 23:29     ` Kees Cook
2024-05-04 11:11 ` [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members Sebastian Huber
2024-05-06  7:08   ` Richard Biener [this message]
2024-05-06 13:29     ` Sebastian Huber
2024-05-06 14:20       ` Qing Zhao
2024-05-07 13:15         ` Sebastian Huber
2024-05-07 14:26           ` Qing Zhao
2024-05-07 17:57             ` Sebastian Huber
2024-05-07 18:34               ` Qing Zhao
2024-05-07 21:52                 ` Kees Cook
2024-05-08  7:25                   ` Richard Biener
2024-05-08 19:28                   ` Qing Zhao
2024-05-07 20:14               ` 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=08858rs4-6qn8-227n-383q-o0ss0p433s07@fhfr.qr \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=qing.zhao@oracle.com \
    --cc=sebastian.huber@embedded-brains.de \
    /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).