Tracking Issue for CStr::from_bytes_until_nul
#95027
Comments
ericseppanen
added
C-tracking-issue
That a better doc that real doc
for exemple, |
|
We could have avoided the |
|
Would it be possible to separately feature gate However, the |
|
Hey @ericseppanen I hope you don't mind, but I've opened stabilization PR #107429 without any |
|
I'm not sure which issue to comment on, but I'm happy with whatever others want to do. I was never sure why the I'll try to find time to rebase that commit and poke the reviewers again. |
|
Okiedoke, as long as you don't have any qualms about the cstr part going stable. Sorry to leapfrog you and start the stabilization, but I wasn't sure if you were still active on github. Yeah, things have a tendency to stall a bit when they're close to the merge phase and there isn't really any open debate or strong need to drive discussion. Not your fault! |
m-ou-se
changed the title
CString/CStr::from_bytes_until_nulCStr::from_bytes_until_nul
Good idea. I've edited this tracking issue so it only covers CStr::from_bytes_until_nul. |
…bilization, r=dtolnay Stabilize feature `cstr_from_bytes_until_nul` This PR seeks to stabilize `cstr_from_bytes_until_nul`. Partially addresses rust-lang#95027 This function has only been on nightly for about 10 months, but I think it is simple enough that there isn't harm discussing stabilization. It has also had at least a handful of mentions on both the user forum and the discord, so it seems like it's already in use or at least known. This needs FCP still. Comment on potential discussion points: - eventual conversion of `CStr` to be a single thin pointer: this function will still be useful to provide a safe way to create a `CStr` after this change. - should this return a length too, to address concerns about the `CStr` change? I don't see it as being particularly useful, and it seems less ergonomic (i.e. returning `Result<(&CStr, usize), FromBytesUntilNulError>`). I think users that also need this length without the additional `strlen` call are likely better off using a combination of other methods, but this is up for discussion - `CString::from_vec_until_nul`: this is also useful, but it doesn't even have a nightly implementation merged yet. I propose feature gating that separately, as opposed to blocking this `CStr` implementation on that Possible alternatives: A user can use `from_bytes_with_nul` on a slice up to `my_slice[..my_slice.iter().find(|c| c == 0).unwrap()]`. However; that is significantly less ergonomic, and is a bit more work for the compiler to optimize compared the direct `memchr` call that this wraps. ## New stable API ```rs // both in core::ffi pub struct FromBytesUntilNulError(()); impl CStr { pub const fn from_bytes_until_nul( bytes: &[u8] ) -> Result<&CStr, FromBytesUntilNulError> } ``` cc `@ericseppanen` original author, `@Mark-Simulacrum` original reviewer, `@m-ou-se` brought up some issues on the thin pointer CStr `@rustbot` modify labels: +T-libs-api +needs-fcp
…bilization, r=dtolnay Stabilize feature `cstr_from_bytes_until_nul` This PR seeks to stabilize `cstr_from_bytes_until_nul`. Partially addresses rust-lang#95027 This function has only been on nightly for about 10 months, but I think it is simple enough that there isn't harm discussing stabilization. It has also had at least a handful of mentions on both the user forum and the discord, so it seems like it's already in use or at least known. This needs FCP still. Comment on potential discussion points: - eventual conversion of `CStr` to be a single thin pointer: this function will still be useful to provide a safe way to create a `CStr` after this change. - should this return a length too, to address concerns about the `CStr` change? I don't see it as being particularly useful, and it seems less ergonomic (i.e. returning `Result<(&CStr, usize), FromBytesUntilNulError>`). I think users that also need this length without the additional `strlen` call are likely better off using a combination of other methods, but this is up for discussion - `CString::from_vec_until_nul`: this is also useful, but it doesn't even have a nightly implementation merged yet. I propose feature gating that separately, as opposed to blocking this `CStr` implementation on that Possible alternatives: A user can use `from_bytes_with_nul` on a slice up to `my_slice[..my_slice.iter().find(|c| c == 0).unwrap()]`. However; that is significantly less ergonomic, and is a bit more work for the compiler to optimize compared the direct `memchr` call that this wraps. ## New stable API ```rs // both in core::ffi pub struct FromBytesUntilNulError(()); impl CStr { pub const fn from_bytes_until_nul( bytes: &[u8] ) -> Result<&CStr, FromBytesUntilNulError> } ``` cc ``@ericseppanen`` original author, ``@Mark-Simulacrum`` original reviewer, ``@m-ou-se`` brought up some issues on the thin pointer CStr ``@rustbot`` modify labels: +T-libs-api +needs-fcp
…bilization, r=dtolnay Stabilize feature `cstr_from_bytes_until_nul` This PR seeks to stabilize `cstr_from_bytes_until_nul`. Partially addresses rust-lang#95027 This function has only been on nightly for about 10 months, but I think it is simple enough that there isn't harm discussing stabilization. It has also had at least a handful of mentions on both the user forum and the discord, so it seems like it's already in use or at least known. This needs FCP still. Comment on potential discussion points: - eventual conversion of `CStr` to be a single thin pointer: this function will still be useful to provide a safe way to create a `CStr` after this change. - should this return a length too, to address concerns about the `CStr` change? I don't see it as being particularly useful, and it seems less ergonomic (i.e. returning `Result<(&CStr, usize), FromBytesUntilNulError>`). I think users that also need this length without the additional `strlen` call are likely better off using a combination of other methods, but this is up for discussion - `CString::from_vec_until_nul`: this is also useful, but it doesn't even have a nightly implementation merged yet. I propose feature gating that separately, as opposed to blocking this `CStr` implementation on that Possible alternatives: A user can use `from_bytes_with_nul` on a slice up to `my_slice[..my_slice.iter().find(|c| c == 0).unwrap()]`. However; that is significantly less ergonomic, and is a bit more work for the compiler to optimize compared the direct `memchr` call that this wraps. ## New stable API ```rs // both in core::ffi pub struct FromBytesUntilNulError(()); impl CStr { pub const fn from_bytes_until_nul( bytes: &[u8] ) -> Result<&CStr, FromBytesUntilNulError> } ``` cc ```@ericseppanen``` original author, ```@Mark-Simulacrum``` original reviewer, ```@m-ou-se``` brought up some issues on the thin pointer CStr ```@rustbot``` modify labels: +T-libs-api +needs-fcp
|
Since |
|
Sure, we can close this. I'm not sure if a new tracking issue is needed, since the |
|
Fwiw that PR is labeled waiting on author, you can comment |
|
Hi @ericseppanen, I'm used to everything from core (and alloc) to be re-exported under the same name in std, so it was a bit of a surprise to see an error message when trying to use |
|
@aswild I don't think anybody would object to a reexport - are you interested in making a PR for that change? It would need to go through FCP (as it changes public API) but I think it's small enough that that could happen on the PR. |
Not intentional; probably just me not knowing I was supposed to do it. |
|
Sure, I can give making a PR a try! I haven't contributed to the standard library before so I apologize in advance if I get the |
Like the other CStr and CString error types, make a re-export for std::ffi::FromBytesUntilNulError. This seems to have slipped through the cracks in the cstr_from_bytes_until_nul implementation and core_c_str migration. Tracking Issue: rust-lang#95027
…r=dtolnay Re-export core::ffi::FromBytesUntilNulError in std::ffi Like the other CStr and CString error types, make a re-export for std::ffi::FromBytesUntilNulError. This seems to have slipped through the cracks in the cstr_from_bytes_until_nul implementation and core_c_str migration. Tracking Issue: rust-lang#95027
Feature gate:
#![feature(cstr_from_bytes_until_nul)]This is a tracking issue for adding member fn to
CStrthat convert from a byte slice, without the caller needing to know where the nul byte is located within the slice.This is intended for use in FFI calls, where a foreign function wrote a string into a Rust-allocated buffer. The existing member fns fall short in this case:
CStr::from_ptris unsafe and may read past the end of the buffer if no nul byte is found.CStr::from_bytes_with_nulonly works if there is exactly one nul byte at the end of the slice.The proposed new member fn (tentatively named
from_bytes_until_nul) is easier and can be used safely on any byte slice.Public API
Steps / History
CStrmethod that accepts any slice containing a nul-terminated string #94984cstr_from_bytes_until_nul#107429 (comment)cstr_from_bytes_until_nul#107429Unresolved Questions
CStringAPI needs to be designed.CStrmethod that accepts any slice containing a nul-terminated string #94984 (comment) for details.The text was updated successfully, but these errors were encountered: