CString should have a "within max length" constructor

[shepmaster]

This Stack Overflow question points out this relatively-common C idiom (trimmed down to show the interesting bits):

let mut errbuf = [0 as c_char, ..256];
c_function_that_fails(errbuf.as_mut_ptr() as *mut libc::c_char);
CString::new(errbuf.as_ptr(), false);

The questioner wonders about the case where errbuf is not correctly set and no NUL bytes occur in the buffer. When we go to use the string, we might merrily walk our way through memory! Since we know the length of errbuf, we should be able to check that there is a NUL in the first X bytes and fail otherwise.

While looking to see how Rust handles this case, I found the following spots that could suffer from the same problem:

• net.rs
• unix/os.rs
• unix/os.rs
• windows/backtrace.rs

I propose we add a new constructor to CString: of_max_len. This would make sure that a NUL byte occurs within a certain number of bytes. If it doesn't, we panic!.

I think we could also make this particular case easier with a constructor like from_slice, which could be passed the slice which would implicitly know its length.

I'm more than welcome to feedback of all kinds!

[alexcrichton]

cc #20507, The purpose of CString is changing pretty radically in that redesign, but this still sounds relevant to the added c_str_to_bytes functions.

[chrish42]

Actually, I guess what I was really asking was for that use case to be made easier. Ideally, I think something like this would be nice:

1. a constructor that builds a CString, which contains a [c_char, ..MAX_LEN], initialized to \0;
2. a function that can convert this to a *mut c_char, to pass to C code (which may write a C string into this buffer);
3. once the C function has returned, a function that converts the array into a Rust string, panicking if there is no \0 within MAX_LEN. (Without needing to repeat said max length.)

Anyways, I think the use case of "allocate a buffer, pass it to a function, which may write a string into it" is not that uncommon for C FFI, and it's be nice if it was easy to do (and in a way that's not error-prone).

(Apologies if I'm getting some of the Rust terminology wrong here. I just started learning Rust about a week ago.)

[alexcrichton]

Note that one idea I had on #20507 was that this use case could be handled with slice::from_raw_buf because the length is known so it can be converted to a slice immediately (and then a find for the 0 and slice afterwards).

@chrish42 for your use cases I would expect:

1. This should in theory be handled with a small vector optimization which can store data inline in the CString itself (which now uses Vec internally).
2. You can currently do that today with let mut buf = [0; LEN]; foo(buf.as_mut_ptr(), buf.len());, I don't think we need to involve CString with that.
3. I think that this is the use case for this bug, which may be solvable with my idea above.

[jimrandomh]

This isn't just for error buffers, and this is very problematic even if the function is guaranteed to set the buffer and terminate it with a null. As part of my first Rust project, I'm trying to call ptsname_r to get a string, and pass the result to open(2). Hours later, I still haven't found a way to do this correctly, even awkwardly. The given example does not compile in current versions of Rust because CString::new doesn't take a second argument, and CString::new panics if there are any nulls in the Vec (including the trailing null). I could write my own strlen, slice the vec, and make a CString that way... but at that point it's clear the language isn't ready for this and my project would need a rewrite later.