add CString::from_vec_until_nul

[ericseppanen]

This adds a fn that converts a Vec into a CString, without requiring the nul byte to be at the end of the Vec. It is intended for the case when an FFI function call wrote a string of unknown length, which from_vec_with_nul doesn't handle easily.

For example,

let mut buffer = vec![0u8; 32];
unsafe {
    some_c_function(buffer.as_mut_ptr(), buffer.len());
}
let result = CString::from_vec_until_nul(buffer).unwrap();

This is a companion to CStr::from_bytes_until_nul (#94984) , and shares the feature gate: cstr_from_bytes_until_nul (tracking issue #95027).

Unresolved questions:

I couldn't decide whether this fn should use its own unique error type, or whether it should share the error type with from_vec_with_nul. In this version I reused the existing error type, but I'm happy to change if that's the better choice.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[ericseppanen]

The biggest downside to sharing the error type is that the names obviously don't match:

pub fn from_vec_until_nul(mut v: Vec<u8>) -> Result<Self, FromVecWithNulError>

FromVecWithNulError also contains a FromBytesWithNulErrorKind enum which is not useful in this impl (because there's only one way this fn can fail.

I also find it odd that FromVecWithNulError returns the Vec that was input, but that member is private. I'm not sure why that choice was made originally-- maybe @poliorcetics would know?

[ericseppanen]

(fixed doc-test typo)

[poliorcetics]

I also find it odd that FromVecWithNulError returns the Vec that was input, but that member is private. I'm not sure why that choice was made originally-- maybe @poliorcetics would know?

To allow extensibility of the internals, as unlikely as it is. There are functions on the type to access it IIRC

[petrochenkov]

I'm going to block this on #94079 (which is almost ready), because all such changes have to be reapplied manually when rebasing #94079.

[ghost]

I think the example on this issue is supposed to consume the buffer:
CString::from_vec_until_nul(&buffer) -> CString::from_vec_until_nul(buffer)

(sorry for the minor nit, the & just jumped out to me as odd)

[ericseppanen]

I think the example on this issue is supposed to consume the buffer: CString::from_vec_until_nul(&buffer) -> CString::from_vec_until_nul(buffer)

Fixed, thanks.

[ericseppanen]

I also find it odd that FromVecWithNulError returns the Vec that was input, but that member is private. I'm not sure why that choice was made originally-- maybe @poliorcetics would know?

To allow extensibility of the internals, as unlikely as it is. There are functions on the type to access it IIRC

Ah, I missed that FromVecWithNulError has as_bytes and into_bytes methods. Thanks for the help!

[bors]

☔ The latest upstream changes (presumably #94079) made this pull request unmergeable. Please resolve the merge conflicts.

[ericseppanen]

Apologies for accidentally closing this; I don't seem to be able to re-open it so I opened a new PR #96186 with the same content.

[jyn514]

@ericseppanen you need to force push back to d4c9367 to be able to reopen the PR. (I think GitHub does this to avoid having two simultaneous PRs open from the same branch.)

[ericseppanen]

@ericseppanen you need to force push back to d4c9367 to be able to reopen the PR. (I think GitHub does this to avoid having two simultaneous PRs open from the same branch.)

I tried that but it didn't seem to do anything.

[jyn514]

I don't see a force push here after https://github.com/rust-lang/rust/compare/d4c93674974e8ef0adc9f36d6cd613c25e598c6d..6fd7e9010db6be7605241c39eab7c5078ee2d5bd. Did you remember to use --force?

[ericseppanen]

@jyn514 I did force push the branch to many different hashes, including the one you mentioned. Github stopped updating the "force-pushed from X to Y" message after the first one; I don't know why. After trying it a bunch of times I gave up and opened a new PR. I have updated the tracking issue to point to the new PR.