On 8/9/19 10:58 AM, Jakub Jelinek wrote:
On Fri, Aug 09, 2019 at 10:51:09AM -0600, Martin Sebor wrote:
That said, we should change this code one way or the other.
There is even less of a guarantee that other compilers support
writing past the end of arrays that have non-zero size than
that they recognize the documented zero-length extension.
We use that everywhere forever, so no.
Just because some invalid code has been in place "forever" doesn't
mean it cannot be changed. Relying on undocumented "extensions"
because they just happen to work with the compilers they have been
exposed to is exactly how naive users get in trouble. Our answer
to reports of "bugs" when the behavior changes is typically: fix
your code. There's little reason to expect other compiler writers
to be any more accommodating.
See e.g. rtx u.fld and u.hwint arrays, tree_exp operands array,
gimple_statement_with_ops op array just to name a few that are
everywhere. Coverity is indeed unhappy about
that, but it would be with [0] certainly too. Another option is
to use maximum possible size where we know it (which is the case of
rtxes and most tree expressions and gimple stmts, but not e.g.
CALL_EXPR or GIMPLE_CALL where there is no easy upper bound.
The solution introduced in C99 is a flexible array. C++
compilers usually support it as well. Those that don't are
likely to support the zero-length array (even Visual C++ does).
If there's a chance that some don't support either do you really
think it's safe to assume they will do something sane with
the [1] hack? If you're concerned that the flexible array syntax
or the zero length array won't compile, add a configure test to
see if it does and use whatever alternative is most appropriate.