linux-kernel - Re: [PATCH v6 2/6] rust: str: implement `Index` for `BStr`

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] [day] [month] [year] [list]

Message-ID: <87a5ajflam.fsf@kernel.org>
Date: Tue, 18 Feb 2025 14:13:21 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Benno Lossin" <benno.lossin@...ton.me>
Cc: "Gary Guo" <gary@...yguo.net>,  "Miguel Ojeda" <ojeda@...nel.org>,
  "Alex Gaynor" <alex.gaynor@...il.com>,  "Boqun Feng"
 <boqun.feng@...il.com>,  Björn Roy Baron
 <bjorn3_gh@...tonmail.com>,
  "Alice Ryhl" <aliceryhl@...gle.com>,  "Masahiro Yamada"
 <masahiroy@...nel.org>,  "Nathan Chancellor" <nathan@...nel.org>,
  "Nicolas Schier" <nicolas@...sle.eu>,  "Luis Chamberlain"
 <mcgrof@...nel.org>,  "Trevor Gross" <tmgross@...ch.edu>,  "Adam
 Bratschi-Kaye" <ark.email@...il.com>,  <rust-for-linux@...r.kernel.org>,
  <linux-kernel@...r.kernel.org>,  <linux-kbuild@...r.kernel.org>,  "Petr
 Pavlu" <petr.pavlu@...e.com>,  "Sami Tolvanen" <samitolvanen@...gle.com>,
  "Daniel Gomez" <da.gomez@...sung.com>,  "Simona Vetter"
 <simona.vetter@...ll.ch>,  "Greg KH" <gregkh@...uxfoundation.org>,
  <linux-modules@...r.kernel.org>
Subject: Re: [PATCH v6 2/6] rust: str: implement `Index` for `BStr`

"Benno Lossin" <benno.lossin@...ton.me> writes:

> On 18.02.25 12:14, Andreas Hindborg wrote:
>> "Gary Guo" <gary@...yguo.net> writes:
>>
>>> On Tue, 11 Feb 2025 21:24:44 +0100
>>> Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>>
>>>> "Gary Guo" <gary@...yguo.net> writes:
>>>>
>>>>> On Tue, 11 Feb 2025 16:57:36 +0100
>>>>> Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>>>>
>>>>>> The `Index` implementation on `BStr` was lost when we switched `BStr` from
>>>>>> a type alias of `[u8]` to a newtype. This patch adds back `Index` by
>>>>>> implementing `Index` for `BStr` when `Index` would be implemented for
>>>>>> `[u8]`.
>>>>>>
>>>>>> Signed-off-by: Andreas Hindborg <a.hindborg@...nel.org>
>>>>>> ---
>>>>>>  rust/kernel/str.rs | 11 +++++++++++
>>>>>>  1 file changed, 11 insertions(+)
>>>>>>
>>>>>> diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs
>>>>>> index 002dcddf7c768..1eb945bed77d6 100644
>>>>>> --- a/rust/kernel/str.rs
>>>>>> +++ b/rust/kernel/str.rs
>>>>>> @@ -114,6 +114,17 @@ fn eq(&self, other: &Self) -> bool {
>>>>>>      }
>>>>>>  }
>>>>>>
>>>>>> +impl<Idx> Index<Idx> for BStr
>>>>>> +where
>>>>>> +    Idx: core::slice::SliceIndex<[u8], Output = [u8]>,
>>>>>
>>>>> I think I'd prefer
>>>>>
>>>>> 	[T]: Index<Idx>,
>>>>
>>>> Is that equivalent?
>>>
>>> Sorry, I meant `[u8]: Index<Idx>`. This makes more semantic sense that
>>> "what ever can index a byte slice, it can also index BStr". This is
>>> also how our CStr and the array primitive type implements its Index
>>> operation.
>>>
>>> They should be equivalent as libcore does
>>>
>>> 	impl<T, I> Index<I> for [T] where I: SliceIndex<[T]> { ... }
>>>
>>
>> What I originally wrote is `Idx` must be usable as an index for `[u8]`,
>> yielding `[u8]` when indexing.
>>
>> The new one you suggest, I parse as `[u8]` should be indexable by `Idx`.
>> This is less info. The compiler will also complain about the missing info:
>>
>> error[E0308]: mismatched types
>>    --> /home/aeh/src/linux-rust/module-params/rust/kernel/str.rs:141:26
>>     |
>> 141 |         BStr::from_bytes(&self.0[index])
>>     |         ---------------- ^^^^^^^^^^^^^^ expected `&[u8]`, found `&<[u8] as Index<Idx>>::Output`
>>     |         |
>>     |         arguments to this function are incorrect
>>     |
>>     = note: expected reference `&[u8]`
>>                found reference `&<[u8] as Index<Idx>>::Output`
>>     = help: consider constraining the associated type `<[u8] as Index<Idx>>::Output` to `[u8]`
>>
>> If I constrain the output it's all fine again:
>>
>>     [u8]: Index<Idx, Output = [u8]>,
>>
>>
>> But as I said, I don't think it matters which direction we put this?
>
> I think it's better to depend on `Index` compared to `SliceIndex`.

I am curious for what reason?


Best regards,
Andreas Hindborg