On 8/12/19 4:17 PM, Martin Sebor wrote: > On 8/12/19 2:04 PM, Jeff Law wrote: >> On 8/9/19 4:14 PM, Martin Sebor wrote: >>> 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. >> Given that we require a C++03 compiler to build GCC, I think we can >> revisit how we represent the trailing array. But that seems independent >> of the bulk of this patch. >> >> Can we separate this issue from the rest of the patch? > > The updated patch I posted is independent of the trailing > [1] array hack: > > https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00643.html I must have dropped this from my queue by accident. I'll go find it and give it a looksie as well.
jeff
