Tracking Issue for `CStr::from_bytes_until_nul`

[ericseppanen]

Feature gate: #![feature(cstr_from_bytes_until_nul)]

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.

Public API

// std::ffi:

pub struct FromBytesUntilNulError(...);

impl CStr {
    pub fn from_bytes_until_nul(bytes: &[u8]) -> Result<&CStr, FromBytesUntilNulError>;
}

Steps / History

• CStr Implementation: add CStr method that accepts any slice containing a nul-terminated string #94984
• Final comment period (FCP): Stabilize feature cstr_from_bytes_until_nul #107429 (comment)
• Stabilization PR: Stabilize feature cstr_from_bytes_until_nul #107429

Unresolved Questions

• CString API needs to be designed.
• With CStr eventually revised to just be a pointer, rather than (ptr, len) pair, then this becomes a little less good. See add CStr method that accepts any slice containing a nul-terminated string #94984 (comment) for details.

[Stargateur]

CStr::from_bytes_with_nul only works if there is exactly one nul byte at the end of the slice.

That a better doc that real doc

ensuring that the byte slice is nul-terminated and does not contain any interior nul bytes.

for exemple, [97, 98, 99, 100, 0, 0, 0, 0] could be interpreted as no interior nul bytes unlike the example b"he\0llo\0".

[jimblandy]

We could have avoided the unsafe block that led to gfx-rs/wgpu#3076 by using this function. I hope it gets stabilized.

[tgross35]

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.

[tgross35]

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

[ericseppanen]

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.

[tgross35]

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]

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?

Good idea. I've edited this tracking issue so it only covers CStr::from_bytes_until_nul.