[PATCH] have chkp skip flexible member arrays (PR #79986)

[Jason Merrill]

On Tue, Mar 21, 2017 at 11:08 AM, Martin Sebor <msebor@gmail.com> wrote:
> On 03/20/2017 10:27 PM, Jason Merrill wrote:
>>
>> On Mon, Mar 20, 2017 at 7:58 PM, Martin Sebor <msebor@gmail.com> wrote:
>>>
>>> On 03/20/2017 05:51 PM, Jason Merrill wrote:
>>>>
>>>> On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor <msebor@gmail.com> wrote:
>>>>>
>>>>>
>>>>> Attached is a minimal patch to avoid an ICE in CHKP upon
>>>>> encountering one form of an initializer for a flexible array
>>>>> member, specifically the empty string:
>>>>>
>>>>>   int f ()
>>>>>   {
>>>>>     struct B { int n; char a[]; };
>>>>>
>>>>>     return ((struct B){ 1, "" }).a[0];
>>>>>   }
>>>>>
>>>>> Although GCC accepts (and doesn't ICE on) non-empty initializers
>>>>> for flexible array members, such as
>>>>>
>>>>>     (struct B){ 1, "123" }
>>>>
>>>> How do you mean?  When I compile this with the C front end, I get
>>>>
>>>> error: non-static initialization of a flexible array member
>>>
>>> I meant that G++ accepts it, doesn't ICE, but emits wrong code.
>>> (it's consistently rejected by the C front end).  Sorry for not
>>> being clear about it.
>>
>> Ah, OK.  It seems to me that the wrong code bug is worth addressing;
>> why does rejecting the code seem risky to you?
>
> I have a few reasons: First, it's not a regression (I raised
> bug 69696 for it in early 2016) so strictly it's out of scope
> for this stage.  Second, there are a number of bugs related
> to the initialization of flexible array members so the fixes
> are probably not going to be contained to a single function
> or file.  Third, the flexible member array changes I made in
> the past were not trivial, took time to develop, and the two
> of us iterated over some of them for weeks.  Despite your
> careful review and my extensive testing some of them
> introduced regressions that are still being patched up.
> Fourth, making a change to reject code this close to a release
> runs the risk of breaking code that has successfully compiled
> in mass rebuilds and others' tests with the new compiler.
> While that could be viewed as a good change for invalid code
> that's exercised at run time, it could also break programs
> where the bad code is never exercised.

Fair enough.  But I think the ICE is preferable to wrong code.

Jason