Martin Sebor <mse...@gmail.com> writes:
> On 06/11/2018 12:08 PM, Richard Sandiford wrote:
>> Martin Sebor <mse...@gmail.com> writes:
>>> @@ -1553,12 +1553,28 @@ struct line *thisline = (struct line *)
>>> thisline->length = this_length;
>>> @end smallexample
>>>
>>> -In ISO C90, you would have to give @code{contents} a length of 1, which
>>> -means either you waste space or complicate the argument to @code{malloc}.
>>> +Although the size of a zero-length array is zero, an array member of
>>> +this kind may increase the size the enclosing type as a result of tail
>>> +padding. The offset of a zero-length array member from the beginning
>>> +of the enclosing structure is the same as the offset of an array with
>>> +one or more elements of the same type. The alignment of a zero-length
>>> +array is the same as the alignment of its elements.
>>>
>>> -In ISO C99, you would use a @dfn{flexible array member}, which is
>>> -slightly different in syntax and semantics:
>>> +Declaring zero-length arrays in other contexts, including as interior
>>> +members of structure objects or as non-member objects is discouraged.
>>> +Accessing elements of zero-length arrays declared in such contexts is
>>> +undefined and may be diagnosed.
>>>
>>> +In the absence of the zero-length array extension, in ISO C90 the
>>> +@code{contents} array in the example above would typically be declared
>>> +to have a single element. Although this technique is discouraged, GCC
>>> +handles trailing one-element array members similarly to zero-length
>>> +arrays.
>>
>> This last sentence seems a bit vague. E.g. GCC should never diagnose
>> an access to element 0 of a 1-element trailing array, whereas (like you
>> say above) it might for zero-length trailing arrays.
>
> GCC doesn't diagnose past-the-end accesses to trailing member
> arrays regardless of their size. I don't think it should start
> diagnosing them for zero-length arrays, and probably not even
> for one-element arrays (at least not in C90 mode). I think in
> the future it would be worthwhile to consider diagnosing past-
> the-end accesses to trailing member arrays of two or more
> elements, but this patch isn't meant to suggest it's done yet.
> At the same time, I do want to leave the door open to diagnosing
> such accesses eventually, so I don't want to go into too much
> detail describing exactly what is and what isn't diagnosed today.
Yeah, agree that we shouldn't go into detail about what is
and isn't diagnosed. I just don't think we should claim that
one-element arrays are treated "similarly" to zero-length arrays
without saying what "similarly" means. They're certainly different
at some level, otherwise the extension wouldn't have been added :-)
If we don't want to give much more detail about this then I think it
would be better to keep the original paragraph:
In ISO C90, you would have to give @code{contents} a length of 1, which
means either you waste space or complicate the argument to @code{malloc}.
instead of the last one. (The other changes look good to me FWIW.)
Noticed later,
> +The preferred mechanism to declare variable-length types like
> +@code{struct line} above is the ISO C99 @dfn{flexible array member},
> +with slightly different in syntax and semantics:
Don't think the s/which is/with/ change is correct here.
Thanks,
Richard
