On 19/06/2012 4:12 AM, Shohei Wada wrote:
Is there any good datatype to copy out and keep the c-string? Of course str is useless in this case, and it seems [c_char] has same problem. (vec::as_buf's signature is as_buf<E, T>(v: [const E], f: fn(*E) -> T) -> T, I may not allowed to return *E from the closure) So I think I should use libc::malloc/memcpy/free and std::c_vec to make sure the c-string survive. Is this right?
_Currently_ you can do what Brian suggested and just make sure the underlying strings live long enough. When we finish moving to slices, we'll provide an interface wherein the user passes an arena into the as_c_str function, which any temporary is allocated inside. In that case you will be safe keeping both the underlying strings (for terminal slices) and the arena (for non-terminal slices) alive and non-reset as long as you keep the pointers alive.
I.e. if you write your code so it keeps the strings alive for the duration of your needs, presently, you will only have a slight additional bit of code to write, to keep an arena alive as well, when we finish the upgrade to slices.
(For users who don't wish to keep an arena around, we'll have a variant of the API that uses a general stack-parallel task-local arena automatically, which it resets at the end of the call. This is generally how we're planning on handling alloca()-like problems, via APIs that take user-provided arenas, but default to use the stack-parallel task-local one, when none is provided.)
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
