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.
Martin
