On Tue, Mar 21, 2017 at 09:08:49AM -0600, Martin Sebor wrote:
> On 03/20/2017 10:27 PM, Jason Merrill wrote:
> > On Mon, Mar 20, 2017 at 7:58 PM, Martin Sebor <mse...@gmail.com> wrote:
> > > On 03/20/2017 05:51 PM, Jason Merrill wrote:
> > > > On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor <mse...@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.
>
> As I understand the schedule, the release is expected sometime
> in early April. I leave on April 2 for a week, so I have only
> until then. I don't think that leaves enough time. I'd be
> uncomfortable taking on a project this late in the cycle that
> could put the release in jeopardy, or that I might have to
> rely on others to finish up.
Since I've also spent some time on this: my take on this is that the C++ FE
should just follow C FE's suit and reject such initializations where
possible; it seems they've never worked reliably anyway, and bring more
harm than good. I don't see that rejecting such code would cause too much
trouble, if any, although the timing could be better.
Marek
