[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72=JVJw_1vrecMDZhReYqJ2anGfhdkZW-ukt-ANDj_Fidw@mail.gmail.com>
Date: Tue, 11 Apr 2023 13:17:19 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Andrea Righi <andrea.righi@...onical.com>
Cc: Kees Cook <kees@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
bjorn3_gh@...tonmail.com, Kees Cook <keescook@...omium.org>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] rust: allow to use INIT_STACK_ALL_ZERO
On Tue, Apr 11, 2023 at 9:11 AM Andrea Righi <andrea.righi@...onical.com> wrote:
>
> Yes, that looks more clear, the name of the option is a bit misleading. :)
>
> To be clear what is going to be removed is
> -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang,
> in this way clang will be compatible with gcc and they can both use
> -ftrivial-auto-var-init=zero.
Exactly, i.e. `-enable` is the one getting removed, but the wording
within it (`knowing-it-will-be-removed-from-clang`) meant that the
`-ftrivial...=zero` one was the one that would be removed, not
`-enable` itself (even if now what will happen is the opposite than
what the option suggested originally).
So when I read the commit message, the "this additional option ... is
going to be removed in the future (as the name of the option
suggests)" sounded wrong, since the name did not suggest that, but
rather that `-ftrivial...=zero` would be removed, not itself (since
that was the original plan).
If I understood the story properly, that is. :)
Thanks for taking a look!
Cheers,
Miguel
Powered by blists - more mailing lists