[PATCH] c/67882 - improve -Warray-bounds for invalid offsetof

[Martin Sebor]

On 10/23/2015 05:13 AM, Bernd Schmidt wrote:
> On 10/21/2015 12:10 AM, Joseph Myers wrote:
>> On Tue, 20 Oct 2015, Bernd Schmidt wrote:
>>>  How about
>>>    &a.v[2].a
>>> and
>>>    &a.v[2].b
>>
>> I don't think either is valid.
>
>>> typedef struct FA5_7 {
>>>    int i;
>>>    char a5_7 [5][7];
>>> } FA5_7;
>>>
>>>      __builtin_offsetof (FA5_7, a5_7 [0][7]),         // { dg-warning
>>> "index" }
>>>      __builtin_offsetof (FA5_7, a5_7 [1][7]),         // { dg-warning
>>> "index" }
>>>      __builtin_offsetof (FA5_7, a5_7 [5][0]),         // { dg-warning
>>> "index" }
>>>      __builtin_offsetof (FA5_7, a5_7 [5][7]),         // { dg-warning
>>> "index" }
>>
>> The last one is certainly invalid.  The one before is arguably invalid as
>> well (in the unary '&' equivalent, &a5_7[5][0] which is equivalent to
>> a5_7[5] + 0, the questionable operation is implicit conversion of a5_7[5]
>> from array to pointer - an array expression gets converted to an
>> expression "that points to the initial element of the array object", but
>> there is no array object a5_7[5] here).
>
> Martin, is this something you're working on, or should I have a go?

I thought I made all the tweaks to these test cases in the last patch:

   https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01946.html

But now that I'm re-reading the answer above I see that Joseph
was suggesting that a5_7[5][0] should be diagnosed when the patch
accepts it as an extension.  I think we do want to accept it
because a5_7 is treated as a flexible array member (as an extension)
and so the upper bound of the major index is unknown. I.e., FA5_7
is defined like so:

   typedef struct FA5_7 {
       int i;
       char a5_7 [5][7];   // treated as char [][7]
    } FA5_7;

Martin