CString behaves strangely with regard to *const and *mut

[wycats]

In the current API, CString::new takes a *const i8, but it has a method as_mut_ptr which returns a *mut i8.

The as_mut_ptr method seems to violate the invariant that the new method is trying to impose.

Perhaps we need CString and MutCString, as well as MutCString::to_c_string?

[erickt]

Ack, that is pretty nasty. I think CString and MutCString sounds like a reasonable approach for this problem.

[huonw]

This is a problem with CVec too.

cc @aturon

(Parameterizable mutability would be another solution, I guess.)

[mzabaluev]

Somewhat orthogonal to the mutability issue, I find the dynamic ownership flag too error-prone, considering that the main use case for CString is returning it by value and the result of doing that with the flag set to false would be a memory leak.

Perhaps CString and CMutString could be dedicated to wrapping allocated buffers, and there should be utilities for wrapping foreign-owned string pointers as &'a [u8] and constructing byte iterators over them.

[mzabaluev]

Both .as_ptr() and .as_mut_ptr() are unsafe, so in principle, anything goes. But as far as I can see the use cases, CString is understood as an immutable wrapper, its main purpose being RAII over a foreign-allocated buffer while string modifications are preferably done elsewhere in Rust code. Perhaps there is no need for the crowbar that is .as_mut_ptr(), because one can always cast pointers explicitly in unsafe code and be aware of the implications.

[alexcrichton]

This was resolved in #20507