From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f172.google.com ([209.85.220.172]:35956 "EHLO mail-qk0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751039AbeCJTJR (ORCPT ); Sat, 10 Mar 2018 14:09:17 -0500 MIME-Version: 1.0 In-Reply-To: References: <20180309200536.GA5670@beast> <20180309160719.154a3158e2d8ee56e43a918f@linux-foundation.org> From: Miguel Ojeda Date: Sat, 10 Mar 2018 20:08:55 +0100 Message-ID: Subject: Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max() To: Linus Torvalds Cc: Kees Cook , Randy Dunlap , Andrew Morton , linux-kernel , Josh Poimboeuf , Rasmus Villemoes , "Gustavo A. R. Silva" , "Tobin C. Harding" , Steven Rostedt , Jonathan Corbet , Chris Mason , Josef Bacik , David Sterba , "David S. Miller" , Alexey Kuznetsov , Hideaki YOSHIFUJI , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Masahiro Yamada , Borislav Petkov , Ian Abbott , Sergey Senozhatsky , Petr Mladek , Andy Shevchenko , Pantelis Antoniou , Linux Btrfs , Network Development , Kernel Hardening Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Sat, Mar 10, 2018 at 6:51 PM, Linus Torvalds wrote: > > So in *historical* context - when a compiler didn't do variable length > arrays at all - the original semantics of C "constant expressions" > actually make a ton of sense. > > You can basically think of a constant expression as something that can > be (historically) handled by the front-end without any real > complexity, and no optimization phases - just evaluating a simple > parse tree with purely compile-time constants. > > So there's a good and perfectly valid reason for why C limits certain > expressions to just a very particular subset. It's not just array > sizes, it's case statements etc too. And those are very much part of > the C standard. > > So an error message like > > warning: ISO C90 requires array sizes to be constant-expressions > > would be technically correct and useful from a portability angle. It > tells you when you're doing something non-portable, and should be > automatically enabled with "-ansi -pedantic", for example. > > So what's misleading is actually the name of the warning and the > message, not that it happens. The warning isn't about "variable > length", it's literally about the rules for what a > "constant-expression" is. > > And in C, the expression (2,3) has a constant _value_ (namely 3), but > it isn't a constant-expression as specified by the language. > > Now, the thing is that once you actually do variable length arrays, > those old front-end rules make no sense any more (outside of the "give > portability warnings" thing). > > Because once you do variable length arrays, you obviously _parse_ > everything just fine, and you're doing to evaluate much more complex > expressions than some limited constant-expression rule. > > And at that point it would make a whole lot more sense to add a *new* > warning that basically says "I have to generate code for a > variable-sized array", if you actually talk about VLA's. > > But that's clearly not what gcc actually did. > > So the problem really is that -Wvla doesn't actually warn about VLA's, > but about something technically completely different. > I *think* I followed your reasoning. For gcc, -Wvla is the "I have to generate code for a variable-sized array" one; but in this case, the array size is the actual issue that you would have liked to be warned about; since people writing: int a[(2,3)]; did not really mean to declare a VLA. Therefore, you say warning them about the "warning: ISO C90 requires array sizes to be constant-expressions" (let's call it -Wpedantic-array-sizes) would be more helpful here instead of saying stuff about VLAs. In my case, I was just expecting gcc to give us both warnings and that's it, instead of trying to be smart and give only the -Wpedantic-array-sizes one (which is the one I was wondering in my previous email about why it was missing). I think it would be clear enough if both warnings are shown are the same time. And it makes sense, since if you write that line in ISO C90 it means there really are 2 things going wrong in the end (fishy syntax while in ISO C90 mode and, due to that, VLA code generated as well), no? Thanks for taking the time to write about the historical context, by the way! Miguel > And that's why those stupid syntactic issues with min/max matter. It's > not whether the end result is a compile-time constant or not, it's > about completely different issues, like whether there is a > comma-expression in it. > > Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miguel Ojeda Subject: Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max() Date: Sat, 10 Mar 2018 20:08:55 +0100 Message-ID: References: <20180309200536.GA5670@beast> <20180309160719.154a3158e2d8ee56e43a918f@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Kees Cook , Randy Dunlap , Andrew Morton , linux-kernel , Josh Poimboeuf , Rasmus Villemoes , "Gustavo A. R. Silva" , "Tobin C. Harding" , Steven Rostedt , Jonathan Corbet , Chris Mason , Josef Bacik , David Sterba , "David S. Miller" , Alexey Kuznetsov , Hideaki YOSHIFUJI , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Masahiro Yamada Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Sat, Mar 10, 2018 at 6:51 PM, Linus Torvalds wrote: > > So in *historical* context - when a compiler didn't do variable length > arrays at all - the original semantics of C "constant expressions" > actually make a ton of sense. > > You can basically think of a constant expression as something that can > be (historically) handled by the front-end without any real > complexity, and no optimization phases - just evaluating a simple > parse tree with purely compile-time constants. > > So there's a good and perfectly valid reason for why C limits certain > expressions to just a very particular subset. It's not just array > sizes, it's case statements etc too. And those are very much part of > the C standard. > > So an error message like > > warning: ISO C90 requires array sizes to be constant-expressions > > would be technically correct and useful from a portability angle. It > tells you when you're doing something non-portable, and should be > automatically enabled with "-ansi -pedantic", for example. > > So what's misleading is actually the name of the warning and the > message, not that it happens. The warning isn't about "variable > length", it's literally about the rules for what a > "constant-expression" is. > > And in C, the expression (2,3) has a constant _value_ (namely 3), but > it isn't a constant-expression as specified by the language. > > Now, the thing is that once you actually do variable length arrays, > those old front-end rules make no sense any more (outside of the "give > portability warnings" thing). > > Because once you do variable length arrays, you obviously _parse_ > everything just fine, and you're doing to evaluate much more complex > expressions than some limited constant-expression rule. > > And at that point it would make a whole lot more sense to add a *new* > warning that basically says "I have to generate code for a > variable-sized array", if you actually talk about VLA's. > > But that's clearly not what gcc actually did. > > So the problem really is that -Wvla doesn't actually warn about VLA's, > but about something technically completely different. > I *think* I followed your reasoning. For gcc, -Wvla is the "I have to generate code for a variable-sized array" one; but in this case, the array size is the actual issue that you would have liked to be warned about; since people writing: int a[(2,3)]; did not really mean to declare a VLA. Therefore, you say warning them about the "warning: ISO C90 requires array sizes to be constant-expressions" (let's call it -Wpedantic-array-sizes) would be more helpful here instead of saying stuff about VLAs. In my case, I was just expecting gcc to give us both warnings and that's it, instead of trying to be smart and give only the -Wpedantic-array-sizes one (which is the one I was wondering in my previous email about why it was missing). I think it would be clear enough if both warnings are shown are the same time. And it makes sense, since if you write that line in ISO C90 it means there really are 2 things going wrong in the end (fishy syntax while in ISO C90 mode and, due to that, VLA code generated as well), no? Thanks for taking the time to write about the historical context, by the way! Miguel > And that's why those stupid syntactic issues with min/max matter. It's > not whether the end result is a compile-time constant or not, it's > about completely different issues, like whether there is a > comma-expression in it. > > Linus