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: <20250619.160844.1477802332578239775.fujita.tomonori@gmail.com>
Date: Thu, 19 Jun 2025 16:08:44 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: miguel.ojeda.sandonis@...il.com, aliceryhl@...gle.com
Cc: fujita.tomonori@...il.com, a.hindborg@...nel.org,
 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

On Wed, 18 Jun 2025 17:47:27 +0200
Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrote:

> On Wed, Jun 18, 2025 at 3:17 PM Alice Ryhl <aliceryhl@...gle.com> wrote:
>>
>> There are also methods such as Duration::as_millis(). Yes, those take
>> &self but &self is equivalent to self for Copy types, so there is no
>> difference. And even if we did treat them differently,
>> Duration::as_millis() is actually borrowed->owned as the return type
>> is not a reference, so ...
> 
> In most cases it may not matter, but even if taking either was exactly
> the same, the point of the discussion(s) was what is more idiomatic,
> i.e. how to spell those signatures.
> 
> I understand you are saying that `Duration::as_millis()` is already a
> stable example from the standard library of something that is not
> borrowed -> borrowed, and thus the guidelines should be understood as
> implying it is fine either way. It is still confusing, as shown by
> these repeated discussions, and on the parameter's side of things,
> they still seem to prefer `&self`, including in the equivalent methods
> of this patch.
> 
> Personally, I would use `self`, and clarify the guidelines.

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
   --> /home/fujita/git/linux-rust/rust/kernel/time/hrtimer.rs:430:17
    |
430 |     fn as_nanos(self) -> i64;
    |                 ^^^^
    |
    = help: consider choosing a less ambiguous name
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#wrong_self_convention
    = note: `-W clippy::wrong-self-convention` implied by `-W clippy::all`
    = help: to override `-W clippy::all` add `#[allow(clippy::wrong_self_convention)]`

https://lore.kernel.org/rust-for-linux/20250610132823.3457263-2-fujita.tomonori@gmail.com/


HrTimerExpires trait needs as_nanos() method and Instant and Delta
need to implement HrTimerExpires trait.

We need a consistent definition of as_nanos() across the
HrTimerExpires trait, and the Instant and Delta structures.

And it would be better if the definition of as_nanos were consistent
with the other as_* methods.

It looks like the conversion from Delta to i64 doesn’t quite fit any
of the categories in the API guidelines. How should it be defined?