Received: by 10.213.65.68 with SMTP id h4csp553519imn; Fri, 16 Mar 2018 11:16:53 -0700 (PDT) X-Google-Smtp-Source: AG47ELsJBeKexqiXEL9DisrQcl4FlR/Ox8xNr5Csavjdx8esnwMBhmZz1MH6fuBHCPiO2nQchMOB X-Received: by 2002:a17:902:bd4b:: with SMTP id b11-v6mr3095512plx.225.1521224213481; Fri, 16 Mar 2018 11:16:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521224213; cv=none; d=google.com; s=arc-20160816; b=efefoUtqqLE1fUNxxcJ6Wl3Mb5Os3+8PGrbKeqZJugmGxALqRsRCFMqE9qDARPgWWP 5J5S48VEVdVKZa7E4tYrXDa/dhU/V4IU51Al9kDru0FS/kJgI13YXL48/EILDQzhLmH2 0AiPY8OB4vA3sjk+nldycJIxLL3xf4CQBYdwwwUfwegLUtQzW815qEvl5MGLbzBKviaG vqGxB1bQ8gsQrjRLlNKNKuH37REumf+xOTTmnMMzw+5CifbWVpjJ1nzirJmDCzlfJBK2 RiIz9dtOz+Ilthu15qIRLLzTcAJphZ5q5hTD9AANm5d/HGEJra0IRQte+BzWjD6kCdP4 y/Hg== 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=8WQaSk3VyiXWjmgf/OGmPuQBq32CcvfWUH5yDz28e+A=; b=VwddLmLhk3dUxbMO3OgtTeudBWVokigkePJvhS3E6oqeJx9s9Kh1IyW7Jl/U5qmh/P IjnB6h96QSLZM8Qi59KpbO+9dEeoZ3SwdG8JW7G3SQwI1OcNnkBAjyZvuhiCGusIoD3j QS0b0tzykurXoUpkLkew7oOUB5/fYy9oYiqzeDNEpPEMwYnWPLCq17/19brRkysii7+V m9IcqjcT00yn/s2rJoWum9yr70t4qsf9AERtkHICNUFgp7fk8JKqFkPcFnSQSDqhJ3UH zo3ucFJvQgND9axYUv26H9X6kaZih77DoKV0VzqIAVq3Qp9sWCk4E8IiFS2iqbBYItwM mKSQ== 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 l5-v6si6252645pls.740.2018.03.16.11.16.39; Fri, 16 Mar 2018 11:16:53 -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 S1753029AbeCPSPT (ORCPT + 99 others); Fri, 16 Mar 2018 14:15:19 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:56306 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751269AbeCPSPO (ORCPT ); Fri, 16 Mar 2018 14:15:14 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1ewtsZ-0005kM-TC; Fri, 16 Mar 2018 18:15:00 +0000 Date: Fri, 16 Mar 2018 18:14:59 +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: <20180316181459.GF30522@ZenIV.linux.org.uk> References: <1521174359-46392-1-git-send-email-keescook@chromium.org> <20180316175502.GE30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180316175502.GE30522@ZenIV.linux.org.uk> 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 05:55:02PM +0000, Al Viro wrote: > 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 s/argue/agree/, sorry > void foo(char c) > { > int a[(c<<1) + 10 - c + 2 - c]; > > a is not a VLA? FWIW, 6.6 starts with constant-expression: conditional-expression for syntax, with 6.6p3 being "Constant expression shall not contain assignment, increment, decrement, function call or comma operators, except when they are contained in a subexpression that is not evaluated", with "The operand of sizeof operator is usually not evaluated (6.5.3.4)" as a footnote. 6.6p10 allows implementation to accept other forms of constant expressions, but arguing that such-and-such construct surely must be recognized as one, when there are perfectly portable ways to achieve the same... Realistically, code like that can come only from macros, and one can wrap the damn thing into 0 * sizeof(..., 0) + just fine there. Which will satisfy the conditions for sizeof argument not being evaluated...