linux-kernel - Re: [PATCH v1 1/2] rust: time: Rename Delta's methods as_micros_ceil and as

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: <87ikks84im.fsf@kernel.org>
Date: Thu, 19 Jun 2025 11:28:01 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>
Cc: "FUJITA Tomonori" <fujita.tomonori@...il.com>,  <aliceryhl@...gle.com>,
  <alex.gaynor@...il.com>,  <ojeda@...nel.org>,
  <anna-maria@...utronix.de>,  <bjorn3_gh@...tonmail.com>,
  <boqun.feng@...il.com>,  <dakr@...nel.org>,  <frederic@...nel.org>,
  <gary@...yguo.net>,  <jstultz@...gle.com>,
  <linux-kernel@...r.kernel.org>,  <lossin@...nel.org>,
  <lyude@...hat.com>,  <rust-for-linux@...r.kernel.org>,
  <sboyd@...nel.org>,  <tglx@...utronix.de>,  <tmgross@...ch.edu>
Subject: Re: [PATCH v1 1/2] rust: time: Rename Delta's methods
 as_micros_ceil and as_millis

"Miguel Ojeda" <miguel.ojeda.sandonis@...il.com> writes:

> On Thu, Jun 19, 2025 at 9:08 AM FUJITA Tomonori
> <fujita.tomonori@...il.com> wrote:
>>
>> So would the function be defined like this?
>>
>> fn as_nanos(self) -> i64;
>>
>> If that's the case, then we've come full circle back to the original
>> problem; Clippy warns against using as_* names for trait methods that
>> take self as follows:
>>
>> warning: methods called `as_*` usually take `self` by reference or `self` by mutable reference
>
> Yeah, the Clippy warning is indeed one more data point that the
> guidelines are confusing to the point of having Clippy complain or,
> more likely, the guidelines' intention is that we should just pick
> `&self`.
>
> If we decide to be OK with `self`s in the kernel for these cases, we
> can simply disable the lint. Doing so means we lose the rest of the
> checking for that lint, sadly.
>
> And, yeah, we are indeed going in circles.
>
> What I would normally suggest for cases like this is answering: what
> would be the best for the kernel's particular case, regardless of
> existing guidelines/lints? Then, if we think it is better to be
> different, and there is enough justification to do so, then try to
> mitigate the lose of the lints, talk to upstream, write our own
> variation of the guidelines, etc.
>
> So I would like to hear if anybody feels strongly about either
> direction, i.e. any other pros/cons that we haven't thought of.

The table at [1] seems to suggest `to_*` or `into_*` being the right
prefix for this situation. It does not fully match `to_*`, as the
conversion is not expensive. It does not match `into_*` as the type is
`Copy`.

I am leaning towards `to_*`, but no strong feelings against `into_*`.

I would not go with `as_*`, I would expect that to borrow.


Best regards,
Andreas Hindborg