From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13184 invoked by alias); 20 Oct 2015 22:10:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 13170 invoked by uid 89); 20 Oct 2015 22:10:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Oct 2015 22:10:50 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Zof7G-0000UX-Qu from joseph_myers@mentor.com ; Tue, 20 Oct 2015 15:10:47 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Tue, 20 Oct 2015 23:10:45 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1Zof7E-0005y9-8L; Tue, 20 Oct 2015 22:10:44 +0000 Date: Tue, 20 Oct 2015 22:19:00 -0000 From: Joseph Myers To: Bernd Schmidt CC: Martin Sebor , Gcc Patch List Subject: Re: [PATCH] c/67882 - improve -Warray-bounds for invalid offsetof In-Reply-To: <5626A5A0.7040003@redhat.com> Message-ID: References: <56172C8C.2070202@gmail.com> <5620ED47.2090009@redhat.com> <56215158.5040404@gmail.com> <56263F80.1090203@t-online.de> <56265E51.4070009@gmail.com> <5626A5A0.7040003@redhat.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2015-10/txt/msg01994.txt.bz2 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