Tracking Issue for methods to go from nul-terminated Vec<u8> to CString

[poliorcetics]

The feature gate for the issue is #![feature(cstring_from_vec_with_nul)].

This adds the following method to CString:

pub unsafe fn from_vec_with_nul_unchecked(v: Vec<u8>) -> Self { /* ... */ }
pub fn from_vec_with_nul(v: Vec<u8>) -> Result<Self, FromVecWithNulError> { /* ... */ }

FromVecWithNulError is a new error type, following the naming pattern of FromBytesWithNulError already existing for CStr::new.

This type, defined as:

#[derive(Clone, PartialEq, Eq, Debug)]
#[unstable(feature = "cstring_from_vec_with_nul", issue = "73179")]
pub struct FromVecWithNulError {
    error_kind: FromBytesWithNulErrorKind,
    bytes: Vec<u8>,
}

It is inspired from the FromUtf8Error type (having as_bytes and into_bytes method) that allows recuperating the input when conversion failed.

The fmt:Display implementation for the type uses the same text as the FromBytesWithNulError, without using the deprecated description method of the Error trait.

#[unstable(feature = "cstring_from_vec_with_nul", issue = "73179")]
impl fmt::Display for FromVecWithNulError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        match self.error_kind {
            FromBytesWithNulErrorKind::InteriorNul(pos) => {
                write!(f, "data provided contains an interior nul byte at pos {}", pos)
            }
            FromBytesWithNulErrorKind::NotNulTerminated => {
                write!(f, "data provided is not nul terminated")
            }
        }
    }
}

Unresolved Questions

• Is this feature needed ? It was asked for issue Creating CString from nul-terminated data #73100 and CStr::from_bytes_with_nul (and its unchecked version) seems to indicates that having an owned version would be logical.
• Names ? I just changed bytes to vec in the names (CStr::from_bytes_with_nul -> CString::from_vec_with_nul and CStr::from_bytes_with_nul_unchecked -> CString::from_vec_with_nul_unchecked).
• Input type for the safe version: I used Vec<u8> but I see CString::new uses Into<Vec<u8>>, should I use that too ?

Implementation history

PR #73139 implements this at the moment, in a unstable form, with documentation and doc tests.

PR #89292 by @CleanCut proposes to stabilize this 🥳

Edit: this being the first time I write a tracking issue, please do not hesitate to tell me if there is something to fix.

[poliorcetics]

@rustbot modify labels to +T-libs, +A-ffi, +C-feature-request

[LeSeulArtichaut]

Couldn't there also be a TryFrom<Vec<u8>> implementation for CString, calling from_vec_with_nul? This would allow to do vec.try_into()? instead of CString::from_vec_with_nul(vec)?.

[poliorcetics]

Couldn't there also be a TryFrom<Vec<u8>> implementation for CString

Added in the current PR (#73139)

Edit: As Dtolnay noted in this comment, there is not one unique behaviour that can be used for a TryFrom implementation, so it has been removed.

[poliorcetics]

A new error type has been added. It is explained in the original post.

[CleanCut]

What is the path to stabilization for this feature?

[poliorcetics]

No one has noted any concerns and it has been unstable for quite some time now, if you want to stabilize it you can make a PR for it (be sure to ping me so I can update the tracking issue).

[CleanCut]

I found competing documentation about stabilizing a library feature in the rustc-dev-guide and the std-dev-guide. The former seems more detailed, but out of date (I can't find any trace of an @T-libs-api team.) They do seem to agree that step 0 should be completing the FCP, so...

@rust-lang/libs can we start the FCP for this feature?

I'm happy to open the stabilization PR once that has been completed.

[CleanCut]

I'm not certain any of my attempted team @-mentions are actually functioning, so I'm going to additionally cc @joshtriplett since they are a library team member and were randomly selected on the PR I'm prepping for this.

[joshtriplett]

Stabilizing this seems reasonable to me.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.