linux-kernel - Re: [PATCH v4] rust: str: add {make,to}

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72n06BCWuHoWbQBrODqgfH8ZGEc6rLhMu86UiYpKdjO3PA@mail.gmail.com>
Date: Tue, 20 Feb 2024 16:45:44 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Danilo Krummrich <dakr@...hat.com>
Cc: Alice Ryhl <aliceryhl@...gle.com>, a.hindborg@...sung.com, alex.gaynor@...il.com, 
	benno.lossin@...ton.me, bjorn3_gh@...tonmail.com, boqun.feng@...il.com, 
	gary@...yguo.net, linux-kernel@...r.kernel.org, ojeda@...nel.org, 
	rust-for-linux@...r.kernel.org, wedsonaf@...il.com
Subject: Re: [PATCH v4] rust: str: add {make,to}_{upper,lower}case() to CString

On Tue, Feb 20, 2024 at 3:53 PM Danilo Krummrich <dakr@...hat.com> wrote:
>
> Just to clarify, I did not say anything else. As mentioned, I think those
> should not even be warnings.

Well, for things like the `return` one, I find it unlikely it will change.

And for other things that there are 2 ways of doing it, what we
typically want is to have one way of doing it, rather than allowing
both ways.

> I'm happy to do that. We should define the scope for that though. I think this
> should be set globally, or at least not per crate. However, I don't really know
> what's the best way to do that. We could pass '-Aclippy::' to the compiler...

The scope is already defined -- it is global, precisely because we
want to keep all kernel code as consistent as possible.

> Is there any objective reason not to be allowed to be explicit here?

What is not objective about wanting to be consistent? How is your
argument objective if ours isn't?

> Well, I generally agree. However, I'm clearly against *blindly* following
> formatters and linters.
>
> Forcing guidelines we don't have objective reasons for will otherwise just annoy
> people and lead to less ideal code for the project. And I intentionally say "for
> the project", since this context is important.

Who is *blindly* following formatters and linters? We don't have
objective reasons?

I don't appreciate the way you are wording things here.

Does it actually lead to "less ideal code", or the opposite?

Cheers,
Miguel