Received: by 10.213.65.68 with SMTP id h4csp543138imn; Fri, 16 Mar 2018 10:59:12 -0700 (PDT) X-Google-Smtp-Source: AG47ELvZwtr1f9QTWM9stpkno014s7b5tdiGIt7oVzLjWy1ZVbSAHvr/nZEV1rCSsll59t/ihqe/ X-Received: by 2002:a17:902:1a4:: with SMTP id b33-v6mr3113836plb.321.1521223152746; Fri, 16 Mar 2018 10:59:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521223152; cv=none; d=google.com; s=arc-20160816; b=DczAy0t77XXpCmdCbiDPINGh6wtPeT5BGPRoHnA8zvySU18pp0H7cDqsTEysds16F6 3tPbnOjMnOiU9Ma9QIRDZrkvJGpbzngnTbdEu1uDiC82FD00Plai0uNYynFMXR22a5Ei 5BYXfiFh8uzOmayoKK1oVGBP996VKjcYvR8WyhtfLdvbePohDwFrk0lJiLbj4Au4cfWQ DhKIZR1XLsdQ8n6bLWoi/Nh+uJAWbab01fISuKj1+UCl98zXBTiWXBW/ePI96vvqDbP2 TNM83nB/OvfXXEjvLhvQtJDXzBQk1Z9N2XhWHK71uUOosWbdc6kbG9xlBTjVXVWhD/W5 FGww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=iER4zW0pEvjByyiW5Z2yip4eHODY+XiNg+gnvBUhfy8=; b=zpAPi2UMf0+H24o9UFG9Ccbhu4o+vldnGAW3OAvTh2573XvOCinDX7o5ODk5JYxYSd bFIQ9dAOmw4yUxoCROKLUKvoR9cxc+9/Q11l5huX/WTDcV4YGVR6MsrVJqTqgZExi/ml UhKstFLGTOVsJAi2dUfZi7N4toH60SLSZnT2uORCDvp0PrSnlUb7W8LpSH9J7UvQs48J zqGVZpaNVQDyw1xNUPF5mQqxNTQ3SM+E/lME+QysBmNlNTAV09HrTLrSI7Pjr6ed3BwV oU0/1jWkXZD9L+cPWwxqV3O2pLEd2SHQ9CntRYJLmOfIFanervjhX/i31T3G1U35vvzI N2AA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o61-v6si6252771pld.692.2018.03.16.10.58.57; Fri, 16 Mar 2018 10:59:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752896AbeCPRzV (ORCPT + 99 others); Fri, 16 Mar 2018 13:55:21 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:55496 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751715AbeCPRzT (ORCPT ); Fri, 16 Mar 2018 13:55:19 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1ewtZG-0004wp-Te; Fri, 16 Mar 2018 17:55:02 +0000 Date: Fri, 16 Mar 2018 17:55:02 +0000 From: Al Viro To: Linus Torvalds Cc: Florian Weimer , Kees Cook , Andrew Morton , Josh Poimboeuf , Rasmus Villemoes , Randy Dunlap , Miguel Ojeda , Ingo Molnar , David Laight , Ian Abbott , linux-input , linux-btrfs , Network Development , Linux Kernel Mailing List , Kernel Hardening Subject: Re: [PATCH v5 0/2] Remove false-positive VLAs when using max() Message-ID: <20180316175502.GE30522@ZenIV.linux.org.uk> References: <1521174359-46392-1-git-send-email-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 16, 2018 at 10:29:16AM -0700, Linus Torvalds wrote: > t.c: In function ‘test’: > t.c:6:6: error: argument to variable-length array is too large > [-Werror=vla-larger-than=] > int array[(1,100)]; > > Gcc people are crazy. That's not them, that's C standard regarding ICE. 1,100 is *not* a constant expression as far as the standard is concerned, and that type is actually a VLA with the size that can be optimized into a compiler-calculated value. Would you argue that in void foo(char c) { int a[(c<<1) + 10 - c + 2 - c]; a is not a VLA? Sure, compiler probably would be able to reduce that expression to 12, but demanding that to be recognized means that compiler must do a bunch of optimizations in the middle of typechecking. expr, constant_expression is not a constant_expression. And in this particular case the standard is not insane - the only reason for using that is typechecking and _that_ can be achieved without violating 6.6p6: sizeof(expr,0) * 0 + ICE *is* an integer constant expression, and it gives you exact same typechecking. So if somebody wants to play odd games, they can do that just fine, without complicating the logics for compilers...