From: Linus Torvalds <torvalds@linux-foundation.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
Randy Dunlap <rdunlap@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
"Tobin C. Harding" <me@tobin.cc>,
Steven Rostedt <rostedt@goodmis.org>,
Jonathan Corbet <corbet@lwn.net>, Chris Mason <clm@fb.com>,
Josef Bacik <jbacik@fb.com>, David Sterba <dsterba@suse.com>,
"David S. Miller" <davem@davemloft.net>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Borislav Petkov <bp@suse.de>, Ian Abbott <abbotti@mev.co.uk>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Petr Mladek <pmladek@suse.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
Linux Btrfs <linux-btrfs@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()
Date: Sat, 10 Mar 2018 09:51:19 -0800 [thread overview]
Message-ID: <CA+55aFw+guiiJ3OavrP-RpFV9NRAF4t=oj3-GDfSyuZ9zBRfdg@mail.gmail.com> (raw)
In-Reply-To: <CANiq72nwg3mMhWeE_bLKdQ5WP+0E+SxxvcuUF=Rn9a1MM+EapQ@mail.gmail.com>
On Sat, Mar 10, 2018 at 9:34 AM, Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> So the warning is probably implemented to just trigger whenever VLAs
> are used but the given standard does not allow them, for all
> languages. The problem is why the ISO C90 frontend is not giving an
> error for using invalid syntax for array sizes to begin with?
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.
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
next prev parent reply other threads:[~2018-03-10 17:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-09 20:05 [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max() Kees Cook
2018-03-09 21:10 ` Linus Torvalds
2018-03-09 21:47 ` Kees Cook
2018-03-11 22:46 ` Tobin C. Harding
2018-03-10 0:07 ` Andrew Morton
2018-03-10 0:28 ` Linus Torvalds
2018-03-10 0:32 ` Andrew Morton
2018-03-10 0:38 ` Linus Torvalds
2018-03-10 1:30 ` Kees Cook
2018-03-10 1:31 ` Kees Cook
2018-03-10 2:37 ` Linus Torvalds
[not found] ` <20180310023907.798690563@goodmis.org>
2018-03-10 3:10 ` [PATCH 3/3] tracing: Rewrite filter logic to be simpler and faster Steven Rostedt
2018-03-10 3:15 ` Steven Rostedt
2018-03-10 3:22 ` Steven Rostedt
2018-03-10 3:11 ` [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max() Randy Dunlap
2018-03-10 6:10 ` Miguel Ojeda
2018-03-10 7:03 ` Miguel Ojeda
2018-03-10 16:04 ` Linus Torvalds
2018-03-10 15:33 ` Kees Cook
2018-03-10 16:11 ` Linus Torvalds
2018-03-10 16:30 ` Linus Torvalds
2018-03-10 17:34 ` Miguel Ojeda
2018-03-10 17:51 ` Linus Torvalds [this message]
2018-03-10 19:08 ` Miguel Ojeda
2018-03-11 11:05 ` Ingo Molnar
2018-03-11 18:23 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+55aFw+guiiJ3OavrP-RpFV9NRAF4t=oj3-GDfSyuZ9zBRfdg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=abbotti@mev.co.uk \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bp@suse.de \
--cc=clm@fb.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=dsterba@suse.com \
--cc=gustavo@embeddedor.com \
--cc=jbacik@fb.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=me@tobin.cc \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pantelis.antoniou@konsulko.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=tglx@linutronix.de \
--cc=yamada.masahiro@socionext.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).