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: <CANiq72m7-5CuKAKDk=G9sauri_sH0nR2TXi8ye5Eji-qaum3sw@mail.gmail.com>
Date: Tue, 20 Feb 2024 17:53:51 +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 4:53 PM Danilo Krummrich <dakr@...hat.com> wrote:
>
> The rational for a convention can't be that it is a convention. Instead
> it should be a convention for an objective reason.

The rationale __for the lint__ is that it is a very established
convention in Rust code.

That is what Clippy is telling you.

You may not agree with the convention (and thus the lint). That is
fine, but it is still a fact that it is the convention, and that is
why I said whoever wrote that Clippy description probably felt that
wording is good enough.

> I'm not saying that we should enforce it otherwise, I just think that we
> should have objective reasons for restrictions.

Again, you seem to be saying we do not have objective reasons.

> However, I also don't see why we should disallow it as long as there is
> no objective reason to do so.

There are objective reasons to do so and we already explained them to you above:

    https://lore.kernel.org/rust-for-linux/CAH5fLggXiXGA_UWCxqqLhMpXe1kepDv2vMG+1jLGaDSzdRHvSw@mail.gmail.com/
    https://lore.kernel.org/rust-for-linux/CANiq72nVkV3+1rt4Mi+Own6KGAzmvR2jf8fFsp9NBu_gy_ob5g@mail.gmail.com/

You disagree? Fine, if you can come up with an argument that convinces
us or a good majority of the kernel that uses Rust, then I will
happily apply the patch.

Personally, I don't particularly care (based on style arguments alone)
whether to write `return` or not. But I do care about not wasting time
on litigating particular choices each time somebody does not like one.

> That's actually what the language did already with early-return vs return at
> the end of the function.
>
> I admit that consistent inconsistency is also kinda consistent though. :-)
>
> The language has various characteristics, maybe that's why it allows both?

Languages may allow a lot of things, but that does not mean we write
the code like IOCCC just because we can.

Nor it does mean that a project should allow every way to write things
either, _especially_ when it is a very widespread convention.

> See above.

I don't see it, sorry. You said you want to be "explicit", but one can
very easily argue you are _not_ being explicit by omitting the
`return` in some cases.

> That's great, although I really don't understand why you think this one is, but
> the other one isn't. What's the difference?

We already told you in this thread several times -- the `return` one
is idiomatic and so on. See the links above.

> I agree, but I also think it should be the other way around. We should have good
> examples and an objective rationale for things we restrict.

Why? To me, we should have good examples and an objective rationale
for things where we actually want to deviate from what everybody else
is doing.

Cheers,
Miguel