Rust in the 6.2 kernel [LWN.net]

Rust in the 6.2 kernel

Posted Nov 17, 2022 19:52 UTC (Thu) by tialaramex (subscriber, #21167)
Parent article: Rust in the 6.2 kernel

Sadly interop with C means &CStr is way less useful than &str.

&str is a (aside from the UTF-8 promise which holds for all Rust strings including CStr I believe) just a slice, a "fat" pointer, an address (of the string) plus a length. Which means operations to get a substring don't mutate the string, they're just different addresses and lengths, the underlying string is unchanged. That includes strip_prefix, split_once, trim_end_matches, and a good many more.

Sadly &CStr can't do that, under the hood it too is an address plus a length (a slice), but it promises the last byte is always 0, ASCII NUL for C compatibility, and of course such substring operations wouldn't deliver that, so &CStr can't efficiently do them. [I guess it could do some of the strip_prefix type operations since those leave the far end alone]

to post comments

Rust in the 6.2 kernel

Posted Nov 17, 2022 21:22 UTC (Thu) by djc (subscriber, #56880) [Link] (3 responses)

Also note that while the article seems to imply that CStr and CString are kernel-specific (and their implementation might well be), normal Rust code also has these types in the std library.

Rust in the 6.2 kernel

Posted Nov 17, 2022 22:57 UTC (Thu) by ssokolow (guest, #94568) [Link] (2 responses)

I suspect it has to do with accessing them through core::ffi::CStr and core::ffi::CString being an experimental/nightly-only feature (core_c_str) and them wanting to get to compatibility with stable compilers as quickly as possible.

It wouldn't surprise me if this contributes to the stabilization of the core_c_str feature.

Rust in the 6.2 kernel

Posted Nov 17, 2022 23:00 UTC (Thu) by ssokolow (guest, #94568) [Link]

Correction: I forgot to update my Dash/Zeal docset. core_c_str got stabilized in 1.64.

It's still possible that they're duplicating it to keep compatibility with earlier revisions of the Rust compiler that distros may be packaging though.

Rust in the 6.2 kernel

Posted Nov 17, 2022 23:02 UTC (Thu) by ssokolow (guest, #94568) [Link]

Correction: ...and "core::ffi::CString"? It's an allocating thing. I clearly need to go to sleep right now.

Rust in the 6.2 kernel

Posted Nov 17, 2022 21:45 UTC (Thu) by tux3 (subscriber, #101245) [Link]

>the UTF-8 promise which holds for all Rust strings including CStr I believe

CStr and CString only seem to promise to be NUL-terminated, I believe any valid char* should make a valid &CStr (which explains why I rememberd &CStr as _not_ cheap to convert to &str)

Rust in the 6.2 kernel

Posted Nov 18, 2022 3:18 UTC (Fri) by droundy (guest, #4559) [Link] (2 responses)

Actually &CStr differs from &str in that it is *not* a slice and doesn't hold a length asking with an address. So while I do prefer the standard &str, &CStr does have the advantage of taking up half as much space.

Rust in the 6.2 kernel

Posted Nov 18, 2022 3:59 UTC (Fri) by ABCD (subscriber, #53650) [Link] (1 responses)

CStr (both kernel::str::CStr and core::ffi::CStr) are implemented as dynamically-sized types (specifically, a newtype wrapper around [u8]), so a &CStr is a fat pointer containing both the pointer to the data and the length of that data, just like a &str or &[u8].

Rust in the 6.2 kernel

Posted Nov 18, 2022 14:21 UTC (Fri) by xav (guest, #18536) [Link]

It is yes, but AFAIK it's an oversight and could be replaced soon with a thin pointer - this is alluded to here for example: https://github.com/m-ou-se/rfcs/blob/c-str-literal/text/3...