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

[Martin Sebor <msebor at gmail dot com>]

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