From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) by sourceware.org (Postfix) with ESMTPS id 99BCE3858D37 for ; Wed, 1 Feb 2023 18:57:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 99BCE3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 67E0D1414D3; Wed, 1 Feb 2023 18:57:11 +0000 (UTC) Received: from pdx1-sub0-mail-a305.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id DAF2F140E84; Wed, 1 Feb 2023 18:57:10 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1675277830; a=rsa-sha256; cv=none; b=G7ROv8hRmgQNwyYWXZZQhKNaUNEfSrcSfaAtCucVTdh0XNSOcYzUUpwHAbRgPTt+3W0fsI T+JUIjmtnBpKkYyrOfesTL+BxMQjBatuGQCd1sWWguT3+DWvyPt1xtwyxxR1dY6OfuXLzQ 0azUvcU/jfSnnUef4yw42KX8JdgmzS5wRSB3WlBkO+x2oI17pYPMs8KoeZFT0pyil/4935 HRQNyC8coO3nAAxkvhxZet/JmMBO5i7VempfrWqEAoBxvk1u/eqqhaeuciijt5tX+xulR5 PLrGbT3X8F2+wr71ectcC/SEHB2GSp4+uQYxP6p4ywP10uDeD2RRB+o5LX6xzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1675277830; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HepIyLFhYwM28PfN2ajE2zAjtIZfwvD9tIa18DgXHe4=; b=VO356jYeLN7p4f3icz2AgJURaQYYfbwsktBOWSCgbiSamxXJRy8EERVwn8p9mrj7nf66Sj XTqSseBBaLn9uVkJUCpXRzMYbFOy3+X+sQp8onMkdscFLs9QW6I+E+kGWA0NsTyDHo/e9k ctKbx4JdHiB6nvc4H9RP3Ma4mNvl5tkDOD/7S7CMRimbONMzB1GqUauDbN/p+EwRuqOalZ vZatmBbmuQpx8A+liN8ea7kKWC8r0+ag9+nJhSIpv4XYy27Aeo4ZH9Q0R3ipXlRycFSRL2 j06Pf8pdc3loMw2FH7CDeVvCEU4sXU8cMx0Ld1LymQsarE4llHR7KncylSJKzw== ARC-Authentication-Results: i=1; rspamd-544f66f495-rm5jj; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Whispering-Sponge: 3f0bfed3380a6195_1675277831178_1247823203 X-MC-Loop-Signature: 1675277831178:2669760504 X-MC-Ingress-Time: 1675277831178 Received: from pdx1-sub0-mail-a305.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.126.30.52 (trex/6.7.1); Wed, 01 Feb 2023 18:57:11 +0000 Received: from [192.168.0.182] (bras-vprn-toroon4834w-lp130-07-174-93-43-36.dsl.bell.ca [174.93.43.36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a305.dreamhost.com (Postfix) with ESMTPSA id 4P6WPL1H1kzS4; Wed, 1 Feb 2023 10:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1675277830; bh=0uRuema/GpbFZc2o7jVDd43ZW8mUqNCtAMD4KZ+Kfaw=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=UJ6TRU0NC2AsZf3f6SpFlkSDk51h13YsvlvLRbNj2DkbzYYt73LuWUqWaKloEPlQl eFxPF44w2DqCNcCDrWqjEsgvrw2Or46f+PoC55Oq73Mym7eiuhHRfI9PIaEV5IpX05 M3Rwm8hPZ0qVzlMBHFY953qwAoYDAdUA0D08y/OR35g9XsUo6bJkPawu7gWTOBieHG yVxi2cdtAPdP78sKpvf6cg9sI8mW7SZd2pd6ECG1hIvOMiQOfW4uonTYJnycyGZbKb UcDkaPB2SbyYe/U3WFrr/KOl32g0OaNyN+L4UcqtAzIUrY9Ajf3q2mT0HQXwG6Ww5p KUPKjbSS9Btnw== Message-ID: Date: Wed, 1 Feb 2023 13:57:08 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH 2/2] Documentation Update. Content-Language: en-US To: Qing Zhao Cc: Richard Biener , gcc Patches , "keescook@chromium.org" References: <20230131141140.3610133-1-qing.zhao@oracle.com> <20230131141140.3610133-3-qing.zhao@oracle.com> <1AB22124-10D2-416D-B1BD-D4FF728AB0E2@oracle.com> From: Siddhesh Poyarekar In-Reply-To: <1AB22124-10D2-416D-B1BD-D4FF728AB0E2@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3031.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-02-01 13:24, Qing Zhao wrote: > > >> On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar 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