[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72kyUr9PGYqHTsNzYn0_cyuYA0vAxHLC08ivxKo5XvOESg@mail.gmail.com>
Date: Sat, 14 Jan 2023 00:15:20 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, linux-kbuild@...r.kernel.org,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nicolas Schier <nicolas@...sle.eu>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
patches@...ts.linux.dev, Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>
Subject: Re: [PATCH 6/6] kbuild: rust_is_available: normalize version matching
On Thu, Jan 12, 2023 at 7:23 AM Masahiro Yamada <masahiroy@...nel.org> wrote:
>
> Maybe, your purpose is to use sed consistently, but
> perhaps you can avoid forking sed if you know the
> format of the first line.
The most unknown format would be the one of the libclang check, where
there may be other lines before the one we are interested in. However,
the pattern expansion would still match newlines, right?
> BTW, what is missing here is, you do not check if
> ${RUSTC} is really rustc.
>
> I can fool this script to print
> "arithmetic expression: expecting primary: "100000 * + 100 * + "
We can test if nothing was printed by `sed` for that (or do it with
shell builtins).
Having said that, I would say fooling the script on purpose is an more
of an oddity compared to the case `MAKEFLAGS` attempts to cover
(please see my reply on the other patch). So if we cover this, then I
would say we should really cover the other one.
Cheers,
Miguel
Powered by blists - more mailing lists