This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] c/67882 - improve -Warray-bounds for invalid offsetof
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Bernd Schmidt <bschmidt at redhat dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 20 Oct 2015 22:10:44 +0000
- Subject: Re: [PATCH] c/67882 - improve -Warray-bounds for invalid offsetof
- Authentication-results: sourceware.org; auth=none
- References: <56172C8C dot 2070202 at gmail dot com> <5620ED47 dot 2090009 at redhat dot com> <56215158 dot 5040404 at gmail dot com> <56263F80 dot 1090203 at t-online dot de> <56265E51 dot 4070009 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1510201650350 dot 7944 at digraph dot polyomino dot org dot uk> <5626A5A0 dot 7040003 at redhat dot com>
On Tue, 20 Oct 2015, Bernd Schmidt wrote:
> Consider
>
> struct t { int a; int b; };
> struct A { struct t v[2]; } a;
>
> So I think we've established that
> &a.v[2]
> is valid, giving a pointer just past the end of the structure. How about
> &a.v[2].a
> and
> &a.v[2].b
> The first of these gives the same pointer just past the end of the array,
> while the second one gives a higher address. I would expect that the second
> one is invalid, but I'm not so sure about the first one. Syntactically we have
> an access to an out-of-bounds field, but the whole expression just computes
> the valid one-past-the-end address.
I don't think either is valid. The address operator '&' requires "a
function designator, the result of a [] or unary * operator, or an lvalue
that designates an object". So because a.v[2].a does not designate an
object, there is undefined behavior. The special case for [] allows the
address of a just-past-end array element to be taken, but that doesn't
apply here.
> I think this has an impact on the tests I quoted in my last mail:
>
> 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" }
>
> Here I think the last one of these is most likely invalid (being 8 bytes past
> the end of the object, rather than just one) and the others valid. Can you
> confirm this? (If the &a.v[2].a example is considered invalid, then I think
> the a5_7[5][0] test would be the equivalent and ought to also be considered
> invalid).
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).
--
Joseph S. Myers
joseph@codesourcery.com