Implement fixed-size-buffer constructors for CString

[Diggsey]

Fixes #20475

I added three variants. Not sure about naming/whether we necessarily need all three.

impl CString {
    // Copy from raw C-style buffer into new CString
    unsafe fn of_fixed_size_raw(ptr: *const c_char, maxlen: usize) -> CString;

    // Copy from byte slice into new CString
    fn of_fixed_size(slice: &[u8]) -> CString;

    // Convert owned byte buffer into CString
    fn from_fixed_size<T: Into<Vec<u8>>>(vec: T) -> CString;
}

For comparison, the existing constructors are:

impl CString {
    // Input must not contain \0
    fn new<T: Into<Vec<u8>>>(t: T) -> Result<CString, NulError>;
    unsafe fn from_vec_unchecked(v: Vec<u8>) -> CString;

    // Must have come from CString::into_raw
    unsafe fn from_raw(ptr: *mut c_char) -> CString;
}

r? @dtolnay

[dtolnay]

First impression: this seems a bit like a new string representation, next to str and CStr and OsStr. Is it possible to expose this in a crate as something like a BoundedCStr type with its own suite of constructors, and conversion to CString? What would the API look like and would it be able to express the same use cases efficiently as the API here?

I don't think we have used the fn of_ naming convention in the standard library yet. Are the two of_ constructors doing something novel that does not match any existing naming convention?

(Have not reviewed the implementation yet.)

[Diggsey]

First impression: this seems a bit like a new string representation

Yes, I'm starting to think this is the case

What would the API look like and would it be able to express the same use cases efficiently as the API here?

I will take a stab at designing this.

I don't think we have used the fn of_ naming convention in the standard library yet. Are the two of_ constructors doing something novel that does not match any existing naming convention?

Typically the constructors do not copy the data - new/from/etc. variants take ownership of the underlying storage. The pattern for constructing an owned type typically looks like: Borrowed::from(...).to_owned() - ultimately the lack of a convention stems from the same issue you pointed out above of this really being a new string representation.

[Diggsey]

@dtolnay https://docs.rs/c_fixed_string/0.1.0/c_fixed_string/

[dtolnay]

Amazing work @Diggsey! I think those types will be more convenient to use than the constructors in this PR because they do a better job capturing how this representation is different from CString. What do you think?

I guess the next thing to decide is whether this c-fixed-string representation is common enough that it makes sense pursuing these in the standard library, or whether we can direct people to a crate instead.

[Diggsey]

Particularly given the amount of API surface that's needed to support this, I think it will have to exist as a crate until it's seen a good amount of usage. Let's close this PR and resolve the original issue with a link to this crate.