You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Tracking Issue for CStr::from_bytes_until_nul #95027
This is a tracking issue for adding member fn to CStr that 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_ptr is unsafe and may read past the end of the buffer if no nul byte is found.
CStr::from_bytes_with_nul only 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.
Would it be possible to separately feature gate cstring_from_bytes_until_nul, instead of both CStr and CString being under cstr_from_bytes_until_nul? I ask because this CStr version is straightforward, has been around for almost a year, is very useful for FFI, and is already mentioned in the forums quite often - imho, probably ready for FCP.
However, the CString version hasn't even merged yet. I just don't think it's worth delaying the CStr stabilization for another year or so while waiting on CString::from_vec_until_nul to get merged & mature a while.
Hey @ericseppanen I hope you don't mind, but I've opened stabilization PR #107429 without any CString implementation. If you have any concerns just let me know and I can close / adjust it as needed
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 CString bit (#96186) stalled, but it's at least partially my own fault as I was too shy to beg for more reviews.
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!
changed the title [-]Tracking Issue for `CString`/`CStr::from_bytes_until_nul`[/-][+]Tracking Issue for `CStr::from_bytes_until_nul`[/+]on Jan 30, 2023
Since cstr_from_bytes_until_nul has been stabilized (#107429 1.69), I think this issue could be closed. @ericseppanen do you perhaps want to start a new tracking issue for cstring_from_bytes_until_nul?
Sure, we can close this. I'm not sure if a new tracking issue is needed, since the CString::from_vec_until_nul PR (#96186) is not making progress. If someone wants to bring it back to life, feel free to persuade the reviewers.
Hi @ericseppanen,
Was it intentional to add FromBytesUntilNulError only in core::ffi and not re-export it in std::ffi?
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 std::ffi::{CStr, FromBytesUntilNulError}.
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 #[stable] attribute wrong at first.
Activity
Stargateur commentedon Aug 1, 2022
That a better doc that real doc
for exemple,
[97, 98, 99, 100, 0, 0, 0, 0]could be interpreted as no interior nul bytes unlike the exampleb"he\0llo\0".jimblandy commentedon Oct 6, 2022
We could have avoided the
unsafeblock that led to gfx-rs/wgpu#3076 by using this function. I hope it gets stabilized.tgross35 commentedon Jan 18, 2023
Would it be possible to separately feature gate
cstring_from_bytes_until_nul, instead of both CStr and CString being undercstr_from_bytes_until_nul? I ask because thisCStrversion is straightforward, has been around for almost a year, is very useful for FFI, and is already mentioned in the forums quite often - imho, probably ready for FCP.However, the
CStringversion hasn't even merged yet. I just don't think it's worth delaying the CStr stabilization for another year or so while waiting onCString::from_vec_until_nulto get merged & mature a while.tgross35 commentedon Jan 28, 2023
Hey @ericseppanen I hope you don't mind, but I've opened stabilization PR #107429 without any
CStringimplementation. If you have any concerns just let me know and I can close / adjust it as neededericseppanen commentedon Jan 29, 2023
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
CStringbit (#96186) stalled, but it's at least partially my own fault as I was too shy to beg for more reviews.I'll try to find time to rebase that commit and poke the reviewers again.
tgross35 commentedon Jan 29, 2023
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!
[-]Tracking Issue for `CString`/`CStr::from_bytes_until_nul`[/-][+]Tracking Issue for `CStr::from_bytes_until_nul`[/+]m-ou-se commentedon Jan 30, 2023
Good idea. I've edited this tracking issue so it only covers CStr::from_bytes_until_nul.
Rollup merge of rust-lang#107429 - tgross35:from-bytes-until-null-sta…
Rollup merge of rust-lang#107429 - tgross35:from-bytes-until-null-sta…
Rollup merge of rust-lang#107429 - tgross35:from-bytes-until-null-sta…
tgross35 commentedon Jul 1, 2023
Since
cstr_from_bytes_until_nulhas been stabilized (#107429 1.69), I think this issue could be closed. @ericseppanen do you perhaps want to start a new tracking issue for cstring_from_bytes_until_nul?ericseppanen commentedon Jul 1, 2023
Sure, we can close this. I'm not sure if a new tracking issue is needed, since the
CString::from_vec_until_nulPR (#96186) is not making progress. If someone wants to bring it back to life, feel free to persuade the reviewers.tgross35 commentedon Jul 1, 2023
Fwiw that PR is labeled waiting on author, you can comment
@rustbot readyto change it to waiting on reviewaswild commentedon Jul 13, 2023
Hi @ericseppanen,
Was it intentional to add
FromBytesUntilNulErroronly incore::ffiand not re-export it instd::ffi?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
std::ffi::{CStr, FromBytesUntilNulError}.tgross35 commentedon Jul 13, 2023
@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.
ericseppanen commentedon Jul 13, 2023
Not intentional; probably just me not knowing I was supposed to do it.
aswild commentedon Jul 14, 2023
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
#[stable]attribute wrong at first.Re-export core::ffi::FromBytesUntilNulError in std::ffi
Rollup merge of rust-lang#113701 - aswild:std-ffi-frombytesuntilnul, …