On 12/05/2016 11:09 AM, Nathan Sidwell wrote:
Jason, Martin. looking at pr78635, I find it related to Martin's patch of 15-12-2015 dealing with flexible array members.Martin's patch makes the following ill-formed: struct Base {int m; char ary[];}; // ends in flexible array - OK struct Derived : Base {}; // base ends in flexible array - Bad The testcase fo pr78635 is similar, except that we have an array of Base objects and are trying to initialize them: struct Base ary[2] = {{1, 'b'}, {2}}; ISTM that we should reject the type 'Base [<whatever>]', rather than make the above ill-formed solely because of the initializer. The array elements must overlap eachother, which I'm sure will break various alias optimizations, regardless of the initializer question. I.e. do we want: struct Base ary[2] = {{1}, {2}}; to be well formed or not? (I'm lobbying for 'no', if that's not clear)
The array definition is rejected in C mode so I agree that it should be diagnosed in C++ as well. That it isn't is being tracked in bug 68489. FWIW, most of the decisions I made in my work with flexible array members in G++ were based on what GCC does. We wanted to allow C11 constructs for compatibility, accommodate safe GCC extensions, and reject any unsafe code (e.g., overlapping members). Since G++ accepted all kinds of questionable code, safe or not, I tried to be careful not to outright reject it only because it looked wrong, just as long as it was (or could be) safe. I didn't want to break programs that happened to rely on it. So I made an effort to only issue warnings for such code (again, as long as it was safe). To that end there's some non-trivial logic that handles some of these cases (e.g., flexible array members in virtual bases). Martin
