Re: [PATCH] update Zero-length array documentation

[Richard Sandiford <richard dot sandiford at arm dot com>]

Martin Sebor <msebor@gmail.com> writes:
> On 06/11/2018 12:08 PM, Richard Sandiford wrote:
>> Martin Sebor <msebor@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