It's nice to see a demonstration of how to do this by hand! But at work, we use Neon <a href="https://github.com/neon-bindings/neon" rel="nofollow">https://github.com/neon-bindings/neon</a> to write production Node.js modules in Rust.
<p><pre><code> #[no_mangle]
pub extern fn string_array() -> *const *const u8 {
let v = vec![
"Hello\0".as_ptr(),
"World\0".as_ptr()
];
v.as_ptr()
}
</code></pre>
This has exactly the same problem as with `CString`; the `Vec` is deallocated at function exit.
> First, we store the Pointer of s string in a variable (p).<p>> Then we use std::mem::forget to release it from the responsibility of Rust.<p>CString::into_raw does that whole song and dance for you.<p>For Vectors you probably want to convert them to boxed slices first, at which point you can use Box::into_raw (to get the slice's head pointer).
I think the article inadvertently reinforces the idea that it's really only practical to scale code that segregates processes and uses streams instead of shared memory. New languages should probably focus on things like the Actor model and optimize stream passing with things like copy-on-write so that no data is actually copied until it's mutated.<p>For this and many other reasons (mainly pushing the onus of managing memory onto the developer instead of automating it) I can't really get behind Rust. I think many other languages like Swift are also barking up the wrong tree by being too pedantic.
I'd recommend against using `std::mem::forget`. Even though it does pretty much the same thing you should probably use `some_cstring.into_raw()` instead. Semantically it's indicating that you are passing ownership of the string to the caller, while `forget()` just indicates that you want to leak the thing.
To the author: it would be nice if your site had a small screens layout.<p>I can't read the article on my phone because too much code is cut off (and the right margin is unpleasantly close to the main text, unlike the left margin).