Tracking issue for CString::{from_ptr, into_ptr}

[alexcrichton]

This is a tracking issue for the unstable cstr_memory feature in the standard library. These methods are likely ready to go as-is modulo naming. Their names should be consistent with Box::{from_raw, into_raw} (currently inconsistent).

cc #27768

[alexcrichton]

This feature is now entering its final comment period for stabilization.

I will post a PR soon for renaming these function to from_raw and into_raw.

[shepmaster]

renaming these function to from_raw and into_raw

Awesome! That makes sense to me.

[bluss]

This rename is important because CStr::from_ptr and CString::from_ptr are so different, but with similar names.

[bluss]

If you use CString::from_ptr on a non-rust allocated thing by mistake, you end up trying to reallocate string literals and things like that. See #27878.

[bluss]

We need to learn from these bugs. Premature dropping of CString leading to dangling pointers, and that some raw pointers transfer ownership and others are "borrowed". Can we use the type system better?

[shepmaster]

@bluss an interesting question. In my mind, once you hit a raw pointer, all bets are off and you have to manage everything yourself. Do you have any thoughts on how to improve that with types?

[geofft]

You can still get some type-safety with raw pointers, though you don't get ownership tracking. I can see a potential API along these lines:

#[repr(i8)] enum RustAllocChar {...}

impl CString {
    fn into_raw(self) -> *const RustAllocChar;
    unsafe fn from_raw(ptr: *const RustAllocChar) -> CString;
}

which lets you write something like

extern {
    fn do_stuff(string: *mut RustAllocChar, free: fn(*mut RustAllocChar));
}

extern fn free(ptr: *mut RustAllocChar) {
    drop(CString::from_raw(ptr));
}

fn main() {
    let s = CString::new("Hello!").unwrap();
    unsafe {do_stuff(s.into_raw(), free)};
}

or for a library

#[no_mangle] // char *mylib_do_stuff(void);
extern fn mylib_do_stuff() -> *mut RustOwnedChar {...}
#[no_mangle] // void mylib_free(char *s);
extern fn mylib_free(s: *mut RustOwnedChar) {...}

So RustAllocChar (or whatever you want to call it -- maybe CChar?) is as valid a binding of C's char as libc::c_char is, but it clearly states that the memory is allocated by Rust: into_raw() no longer returns a type that is indistinguishable from foreign-allocated, otherwise-owned, or static strings. So it's harder to leak it by passing it somewhere where *const c_char was expected, and it's harder to pass the result of .as_ptr() (which is only valid until the CString goes out of scope) where you really wanted .into_ptr(), since they have different types. And it's harder to accidentally free things that shouldn't be freed, because they won't have type *const RustAllocChar.