From: Boqun Feng <boqun.feng@gmail.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: Alice Ryhl <alice@ryhl.io>, Danilo Krummrich <dakr@redhat.com>,
ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com,
gary@garyguo.net, bjorn3_gh@protonmail.com,
benno.lossin@proton.me, a.hindborg@samsung.com,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] rust: str: add {make,to}_{upper,lower}case() to CString
Date: Thu, 15 Feb 2024 08:51:50 -0800 [thread overview]
Message-ID: <Zc5BJvyGIXgDQ21j@boqun-archlinux> (raw)
In-Reply-To: <CAH5fLghO6Jy_hJXhRU_+eBSDHHveAvEOJA6fNkmMS9mqHvS6iQ@mail.gmail.com>
On Thu, Feb 15, 2024 at 10:38:07AM +0100, Alice Ryhl wrote:
> On Thu, Feb 15, 2024 at 2:18 AM Boqun Feng <boqun.feng@gmail.com> wrote:
> >
> > On Wed, Feb 14, 2024 at 08:59:06PM +0100, Alice Ryhl wrote:
> > > On 2/14/24 20:27, Boqun Feng wrote:
> > > > On Wed, Feb 14, 2024 at 06:24:10PM +0100, Danilo Krummrich wrote:
> > > > > --- a/rust/kernel/str.rs
> > > > > +++ b/rust/kernel/str.rs
> > > > > @@ -5,7 +5,7 @@
> > > > > use alloc::alloc::AllocError;
> > > > > use alloc::vec::Vec;
> > > > > use core::fmt::{self, Write};
> > > > > -use core::ops::{self, Deref, Index};
> > > > > +use core::ops::{self, Deref, DerefMut, Index};
> > > > > use crate::{
> > > > > bindings,
> > > > > @@ -143,6 +143,19 @@ pub const fn from_bytes_with_nul(bytes: &[u8]) -> Result<&Self, CStrConvertError
> > > > > unsafe { core::mem::transmute(bytes) }
> > > > > }
> > > > > + /// Creates a mutable [`CStr`] from a `[u8]` without performing any
> > > > > + /// additional checks.
> > > > > + ///
> > > > > + /// # Safety
> > > > > + ///
> > > > > + /// `bytes` *must* end with a `NUL` byte, and should only have a single
> > > > > + /// `NUL` byte (or the string will be truncated).
> > > > > + #[inline]
> > > > > + pub const unsafe fn from_bytes_with_nul_unchecked_mut(bytes: &mut [u8]) -> &mut CStr {
> > > > > + // SAFETY: Properties of `bytes` guaranteed by the safety precondition.
> > > > > + unsafe { &mut *(bytes as *mut [u8] as *mut CStr) }
> > > >
> > > > First `.cast::<[u8]>().cast::<CStr>()` is preferred than `as`. Besides,
> > > > I think the dereference (or reborrow) is only safe if `CStr` is
> > > > `#[repr(transparent)]. I.e.
> > > >
> > > > #[repr(transparent)]
> > > > pub struct CStr([u8]);
> > > >
> > > > with that you can implement the function as (you can still use `cast()`
> > > > implementation, but I sometimes find `transmute` is more simple).
> > > >
> > > > pub const unsafe fn from_bytes_with_nul_unchecked_mut(bytes: &mut [u8]) -> &mut CStr {
> > > > // SAFETY: `CStr` is transparent to `[u8]`, so the transmute is
> > > > // safe to do, and per the function safety requirement, `bytes`
> > > > // is a valid `CStr`.
> > > > unsafe { core::mem::transmute(bytes) }
> > > > }
> > > >
> > > > but this is just my thought, better wait for others' feedback as well.
> > >
> > > Transmuting references is generally frowned upon. It's better to use a
> > > pointer cast.
> > >
> >
> > Ok, but honestly, I don't think the pointer casting is better ;-) What
> > wants to be done here is simply converting a `&mut [u8]` to `&mut CStr`,
> > adding two levels of pointer casting is kinda noise. (Also
> > `from_bytes_with_nul` uses `transmute` as well).
>
> Here's my logic for preferring pointer casts: Transmute raises
> questions about the layout of fat pointers, whereas pointer casts are
> obviously okay.
>
But in this case, eventually you need to worry about fat pointer layout
when you dereference the `*mut CStr`, right? In other words, the
dereference is only safe if `*mut [u8]` has the same fat pointer layout
as `*mut CStr`. I prefer to transmute here because it's a newtype
paradigm, and transmute kinda makes that clear.
Regards,
Boqun
> Alice
next prev parent reply other threads:[~2024-02-15 16:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 17:24 [PATCH v3] rust: str: add {make,to}_{upper,lower}case() to CString Danilo Krummrich
2024-02-14 19:27 ` Boqun Feng
2024-02-14 19:59 ` Alice Ryhl
2024-02-15 1:18 ` Boqun Feng
2024-02-15 9:38 ` Alice Ryhl
2024-02-15 16:51 ` Boqun Feng [this message]
2024-02-16 9:09 ` Alice Ryhl
2024-02-16 16:53 ` Alice Ryhl
2024-02-16 17:11 ` Danilo Krummrich
2024-02-16 19:25 ` Alice Ryhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zc5BJvyGIXgDQ21j@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@samsung.com \
--cc=alex.gaynor@gmail.com \
--cc=alice@ryhl.io \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=dakr@redhat.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=wedsonaf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.