On Sat Jan 3, 2026 at 7:14 PM JST, Danilo Krummrich wrote:
> On Sat Jan 3, 2026 at 4:37 AM CET, John Hubbard wrote:
>> On 12/15/25 8:27 PM, Alexandre Courbot wrote:
>>> The core library's `CStr` has a `from_bytes_until_nul` method that we
>>> can leverage to simplify this function.
>>> 
>>> Reviewed-by: Lyude Paul <[email protected]>
>>> Signed-off-by: Alexandre Courbot <[email protected]>
>>> ---
>>>  drivers/gpu/nova-core/util.rs | 9 ++-------
>>>  1 file changed, 2 insertions(+), 7 deletions(-)
>>> 
>>> diff --git a/drivers/gpu/nova-core/util.rs b/drivers/gpu/nova-core/util.rs
>>> index 8b2a4b99c55b..2cccbce78c14 100644
>>> --- a/drivers/gpu/nova-core/util.rs
>>> +++ b/drivers/gpu/nova-core/util.rs
>>> @@ -2,15 +2,10 @@
>>>  
>>>  /// Converts a null-terminated byte slice to a string, or `None` if the 
>>> array does not
>>>  /// contains any null byte or contains invalid characters.
>>> -///
>>> -/// Contrary to [`core::ffi::CStr::from_bytes_with_nul`], the null byte 
>>> can be anywhere in the
>>> -/// slice, and not only in the last position.
>>>  pub(crate) fn str_from_null_terminated(bytes: &[u8]) -> Option<&str> {
>>>      use core::ffi::CStr;
>>>  
>>> -    bytes
>>> -        .iter()
>>> -        .position(|&b| b == 0)
>>> -        .and_then(|null_pos| 
>>> CStr::from_bytes_with_nul(&bytes[..=null_pos]).ok())
>>> +    CStr::from_bytes_until_nul(bytes)
>>> +        .ok()
>>
>> I guess I should have reviewed this patch, before creating my version of 
>> this.
>> I went so far as to delete this file entirely, see if you prefer that, it's
>> otherwise the same core idea, but with more cleanup. [1]
>>
>> [1] https://lore.kernel.org/[email protected]
>
> Yes, let's remove str_from_null_terminated() entirely.

Removing that method is perfectly fine IMHO, it was only using in a
couple of places and is easily emulated.

>
>>>          .and_then(|cstr| cstr.to_str().ok())
>
> Additionally, why do we return an Option here? While an error can only ever 
> happen if
> the given slice does not contain any NULL byte, I don't see why we discard the
> error code.

I guess I didn't want to change the function's prototype, but yeah this
is sloppy and another good reason to get rid of it.

I'll respin the series once the patches in -fixes are visible in -next.

Reply via email to