[PATCH 2/2] Documentation Update.

[Siddhesh Poyarekar]

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