From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23250 invoked by alias); 10 Nov 2015 00:02:28 -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 23230 invoked by uid 89); 10 Nov 2015 00:02:27 -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, 10 Nov 2015 00:02:26 +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 1ZvwOD-0001hN-6j from joseph_myers@mentor.com ; Mon, 09 Nov 2015 16:02:21 -0800 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, 10 Nov 2015 00:02:18 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1ZvwO8-00078K-SI; Tue, 10 Nov 2015 00:02:16 +0000 Date: Tue, 10 Nov 2015 00:02:00 -0000 From: Joseph Myers To: Segher Boessenkool CC: Bernd Schmidt , Martin Sebor , "Gcc Patch List" Subject: Re: [PATCH] c/67882 - improve -Warray-bounds for invalid offsetof In-Reply-To: <20151107233804.GB9982@gate.crashing.org> 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> <20151107233804.GB9982@gate.crashing.org> 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-11/txt/msg01137.txt.bz2 On Sat, 7 Nov 2015, Segher Boessenkool wrote: > > 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). > > C11, 6.5.2.1/3: > Successive subscript operators designate an element of a > multidimensional array object. If E is an n-dimensional array (n >= 2) > with dimensions i x j x . . . x k, then E (used as other than an lvalue) > is converted to a pointer to an (n - 1)-dimensional array with > dimensions j x . . . x k. If the unary * operator is applied to this > pointer explicitly, or implicitly as a result of subscripting, the > result is the referenced (n - 1)-dimensional array, which itself is > converted into a pointer if used as other than an lvalue. It follows > from this that arrays are stored in row-major order (last subscript > varies fastest). > > As far as I see, a5_7[5] here is never treated as an array, just as a > pointer, and &a5_7[5][0] is valid. As usual, based on taking the address, not offsetof where there's the open question of whether the C standard actually requires support for anything other than a single element name there: a5_7[5] is an expression of array type. The only way for it to be treated as a pointer is for it to be converted implicitly to pointer type. That implicit conversion is what I think is problematic. Only once the implicit conversion has taken place do the special rules about &A[B] meaning A + B take effect. But since the problem I see is with the conversion of A to a pointer, you still have undefined behavior. The paragraph you quote seems to not to add anything to the semantics defined elsewhere in the standard; it's purely descriptive of some consequences of those semantics. Whether we wish to be more permissive about some such cases (depending on -Warray-bounds=N) is a pragmatic matter depending on the extent to which they are used in practice. -- Joseph S. Myers joseph@codesourcery.com