Incorrect const-ness on CString::new argument

[canndrew]

The signature of CString::new is CString::new(buf: *const i8, owns_buffer: bool). The problem with this is that if the new CString does own the buffer it's going to free it. In which case buf should be a *mut i8 not a *const i8. However making buf: *mut i8 doesn't account for the case where the CString doesn't own the buffer and the buffer is immutable.

To fix this CString::new should be split into two functions:

unsafe fn CString::new(buf: *const i8) -> CString;
unsafe fn CString::new_owned(buf: *mut i8) -> CString;

[nodakai]

Because CString basically doesn't write anything into the memory chunk pointed by buf, I think taking *const c_char as an argument is OK. And dereferencing a raw pointer is always unsafe regardless whether it's mut or const, after all.

However I also felt unconfortable with CString::new() and want to split it into two functions. Choosing a correct one from either CString::new(buf, true) or CString::new(buf, false) is a mental burden (bor both of reading and writing.) In fact, we rarely want to parametrize the 2nd argument; for example, all 25 invocations of CString::new() in rust/src used literal true or false.

My idea is naming them CString::as_owner(buf) (for the true case) and CString::as_view(buf) (for the false case) but I don't know how they sound to native English speakers. It may be unclear they are so-called constructors.

[canndrew]

@nodokai I had already written the patch when I read your comment so I went with new and new_owned.

[alexcrichton]

This was since resolved in #20507