From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109392 invoked by alias); 28 Oct 2015 11:28:06 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 109173 invoked by uid 55); 28 Oct 2015 11:28:01 -0000 From: "ch3root at openwall dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/68065] Size calculations for VLAs can overflow Date: Wed, 28 Oct 2015 11:28:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 5.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ch3root at openwall dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-10/txt/msg02332.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065 --- Comment #10 from Alexander Cherepanov --- On 2015-10-27 20:09, joseph at codesourcery dot com wrote: > I think it's undefined at the point where a type exceeds the limit on the > size of an object This would probably be the most reasonable approach but it's not clear if the text of the standard supports it. E.g., the list of UB (C11, J.2p1) includes this one: - The size expression in an array declaration is not a constant expression and evaluates at program execution time to a nonpositive value (6.7.6.2). but I don't see anything like what you described. Perhaps I'm missing something? > (half the address space minus one byte), And this particular value for the limit on the size of an object is troublesome because it's completely undocumented (AFAICT) and goes against what the standard hints to (whole idea of size_t becomes useless, right?). It is also not supported by glibc (malloc), can lead to vulnerabilities etc. etc. but this discussion is for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 . > whether or not > sizeof is used or any object with that type is constructed - that is, as > soon as the language semantics involve evaluation of the array sizes for > the VLA type in question. (If the sizes are neither evaluated nor > required, e.g. sizeof (int (*)[size]), or when replaced by [*] at function > prototype scope, I don't consider that undefined; if required but not > evaluated, as in certain obscure cases of conditional expressions, that's > a different case of undefined behavior.) This is also very nice approach. (Although it seems to differ from the approach to non-VLA arrays in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68107#c1 .) But, again, I don't see how to tie it to the standard. It doesn't mean that this approach is wrong, the standard probably just lacks necessary rules. But it would be nice to make it clear which rules are from the standard and which are gcc's own.