public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Qing Zhao <qing.zhao@oracle.com>
Cc: Richard Biener <rguenther@suse.de>,
	gcc Patches <gcc-patches@gcc.gnu.org>,
	"keescook@chromium.org" <keescook@chromium.org>
Subject: Re: [PATCH 2/2] Documentation Update.
Date: Wed, 1 Feb 2023 13:57:08 -0500	[thread overview]
Message-ID: <b214fe7e-583a-f9ab-7e46-b03c440a4543@gotplt.org> (raw)
In-Reply-To: <1AB22124-10D2-416D-B1BD-D4FF728AB0E2@oracle.com>

On 2023-02-01 13:24, Qing Zhao wrote:
> 
> 
>> On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>>
>> On 2023-01-31 09:11, Qing Zhao wrote:
>>> Update documentation to clarify a GCC extension on structure with
>>> flexible array member being nested in another structure.
>>> gcc/ChangeLog:
>>> 	* doc/extend.texi: Document GCC extension on a structure containing
>>> 	a flexible array member to be a member of another structure.
>>
>> Should this resolve pr#77650 since the proposed action there appears to be to document these semantics?
> 
> My understanding of pr77650 is specifically for documentation on the following case:
> 
> The structure with a flexible array member is the middle field of another structure.
> 
> Which I added in the documentation as the 2nd situation.
> However, I am still not very comfortable on my current clarification on this situation: how should we document on
> the expected gcc behavior to handle such situation?

I reckon wording that dissuades programmers from using this might be 
appropriate, i.e. don't rely on this and if you already have such nested 
flex arrays, change code to remove them.

>>> +In the above, @code{flex_data.data[]} is allowed to be extended flexibly to
>>> +the padding. E.g, up to 4 elements.

"""
... Relying on space in struct padding is bad programming practice and 
any code relying on this behaviour should be modified to ensure that 
flexible array members only end up at the ends of arrays.  The 
`-pedantic` flag should help identify such uses.
"""

Although -pedantic will also flag on flex arrays nested in structs even 
if they're at the end of the parent struct, so my suggestion on the 
warning is not really perfect.

Sid

  reply	other threads:[~2023-02-01 18:57 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-31 14:11 [PATCH 0/2]PR101832: Handle component_ref to a structure/union field including flexible array member for builtin_object_size Qing Zhao
2023-01-31 14:11 ` [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832] Qing Zhao
2023-02-01 11:41   ` Richard Biener
2023-02-01 14:19     ` Qing Zhao
2023-02-02  8:07       ` Richard Biener
2023-02-02 13:52         ` Qing Zhao
2023-02-02 13:54           ` Richard Biener
2023-02-02 14:38             ` Qing Zhao
2023-02-03  7:49               ` Richard Biener
2023-02-03 13:17                 ` Qing Zhao
2023-02-06  9:31                   ` Richard Biener
2023-02-06 14:38                     ` Qing Zhao
2023-02-06 23:14                       ` Joseph Myers
2023-02-07 14:54                         ` Qing Zhao
2023-02-07 19:17                           ` Joseph Myers
2023-02-07 19:57                             ` Qing Zhao
2023-02-07 23:37                               ` Joseph Myers
2023-02-08 15:06                                 ` Qing Zhao
2023-02-08 19:09                                   ` Joseph Myers
2023-02-08 19:20                                     ` Siddhesh Poyarekar
2023-02-08 20:51                                       ` Joseph Myers
2023-02-08 22:53                                       ` Qing Zhao
2023-02-08 23:18                                     ` Qing Zhao
2023-02-09 14:40                                       ` Qing Zhao
2023-02-09 16:46                                         ` Kees Cook
2023-02-10 15:25                                           ` Qing Zhao
2023-02-09 10:35                                   ` Richard Biener
2023-02-09 13:44                                     ` Qing Zhao
2023-02-07 15:28                         ` Siddhesh Poyarekar
2023-02-07 15:38                           ` Qing Zhao
2023-02-01 16:48   ` Siddhesh Poyarekar
2023-02-01 18:20     ` Qing Zhao
2023-01-31 14:11 ` [PATCH 2/2] Documentation Update Qing Zhao
2023-02-01 16:55   ` Siddhesh Poyarekar
2023-02-01 18:24     ` Qing Zhao
2023-02-01 18:57       ` Siddhesh Poyarekar [this message]
2023-02-01 19:19         ` Qing Zhao
2023-02-02  8:33         ` Richard Biener
2023-02-02 14:31           ` Qing Zhao
2023-02-02 17:05             ` Kees Cook
2023-02-03 15:56               ` Jeff Law
2023-02-03  4:25           ` Siddhesh Poyarekar
2023-02-03 14:52             ` Qing Zhao
2023-02-03 20:55             ` Joseph Myers
2023-02-03 22:38               ` 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=b214fe7e-583a-f9ab-7e46-b03c440a4543@gotplt.org \
    --to=siddhesh@gotplt.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=keescook@chromium.org \
    --cc=qing.zhao@oracle.com \
    --cc=rguenther@suse.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).