|
Message-ID: <CA+55aFyuQZ-cYxPeGF2VJu2GjzznQTua6sVBi4+CFdUi+=+Ajw@mail.gmail.com> Date: Tue, 6 Mar 2018 14:41:55 -0800 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Steven Rostedt <rostedt@...dmis.org> Cc: Arnd Bergmann <arnd@...db.de>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Daniel Micay <danielmicay@...il.com>, Ingo Molnar <mingo@...nel.org>, Kees Cook <keescook@...omium.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Alexander Popov <alex.popov@...ux.com>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, PaX Team <pageexec@...email.hu>, Brad Spengler <spender@...ecurity.net>, Andy Lutomirski <luto@...nel.org>, Tycho Andersen <tycho@...ho.ws>, Laura Abbott <labbott@...hat.com>, Mark Rutland <mark.rutland@....com>, Borislav Petkov <bp@...en8.de>, Richard Sandiford <richard.sandiford@....com>, Thomas Gleixner <tglx@...utronix.de>, "H . Peter Anvin" <hpa@...or.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, "Dmitry V . Levin" <ldv@...linux.org>, Emese Revfy <re.emese@...il.com>, Jonathan Corbet <corbet@....net>, Andrey Ryabinin <aryabinin@...tuozzo.com>, "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, Thomas Garnier <thgarnie@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Alexei Starovoitov <ast@...nel.org>, Josef Bacik <jbacik@...com>, Masami Hiramatsu <mhiramat@...nel.org>, Nicholas Piggin <npiggin@...il.com>, Al Viro <viro@...iv.linux.org.uk>, "David S . Miller" <davem@...emloft.net>, Ding Tianhong <dingtianhong@...wei.com>, David Woodhouse <dwmw@...zon.co.uk>, Josh Poimboeuf <jpoimboe@...hat.com>, Dominik Brodowski <linux@...inikbrodowski.net>, Juergen Gross <jgross@...e.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Dan Williams <dan.j.williams@...el.com>, Mathias Krause <minipli@...glemail.com>, Vikas Shivappa <vikas.shivappa@...ux.intel.com>, Kyle Huey <me@...ehuey.com>, Dmitry Safonov <dsafonov@...tuozzo.com>, Will Deacon <will.deacon@....com>, X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH RFC v9 4/7] x86/entry: Erase kernel stack in syscall_trace_enter() On Tue, Mar 6, 2018 at 2:29 PM, Steven Rostedt <rostedt@...dmis.org> wrote: > > Yeah but I would argue that static variables are different. Not really. You're basically saying "I'd like my language to have intrinsic undefined behavior, so that when I hit a bug that might trigger that undefined behavior I get a warning":. Do such bugs happen? Sure. But _other_ bugs happen all the time, and the ONLY real reason you are so adamant about _that_ particular warning, is that "undefined behavior" is such a serious problem. Think about that for a second. Make the serious problem go away, and the warning MAKES NO SENSE. Do you want a compiler to warn you when you write code like this: double area(double radius) { return radius*2*pi; } just because it's obviously buggy shit? And do you *really* expect a compiler warning for that kind of obviously buggy shit? I bet you don't. And if you don't, why do you expect a compiler warning for int g(int c) { int i = 0; if (c) i = 1; return i; } which is *literally* what your example would have been had just C been specified to avoid unnecessary undefined behavior? Seriously. Look at that example, and tell me that gcc should warn about it. I can imagine the warning ("warning: function 'g()' is stupidly written, just use !!c"). But nobody sane really would expect a compiler to warn about it. Once a compiler is that smart, you wouldn't write code for it, you'd just ask it to generate code from a description. Guys, everybody agrees that C isn't a safe language. Do you think that lack of safety is a _good_ thing? Do you realize that most of the lack of safety is almost directly about flexibility, simplicity, and good code generation? But what if I told you that some of the lack of safety doesn't actually add to flexibility, simplicity, _or_ good code generation? Wouldn't you say "we don't want it to be unsafe" then? I'm literally telling you that lack of variable initialization is almost purely a bad thing. C would be a safer language, with less undefined behavior, if it just made the initialization of automatic variables be something you cannot avoid. For scalars in particular, there is basically no downside. Aggregate types really are much less black-and-white. Linus
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.