OpenE2K/rust
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Document that CStrings live in the libc heap

Browse Source 
Closes issue #17067 and improves pr #17355
This commit is contained in:
gamazeps 2014-09-18 12:13:30 +02:00
parent 9ce2c51c46
commit 6a37692ecb
1 changed files with 8 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
src/librustrt/c_str.rs
View File

@ -36,10 +36,10 @@ not tied to the lifetime of the original string/data buffer). If C strings are
heavily used in applications, then caching may be advisable to prevent
unnecessary amounts of allocations.
Be carefull to remember that the memory is managed by libc's malloc and not
by jemalloc which is the 'normal' rust memory allocator.
That means that the CString pointers should only be freed with
alloc::libc_heap::malloc_raw if you intend to do that on your own.
Be carefull to remember that the memory is managed by C allocator API and not
by Rust allocator API.
That means that the CString pointers should only be freed with C allocator API
if you intend to do that on your own.
An example of creating and using a C string would be:
@ -97,7 +97,7 @@ pub struct CString {
impl Clone for CString {
/// Clone this CString into a new, uniquely owned CString. For safety
/// reasons, this is always a deep clone with the memory allocated
/// with libc's malloc, rather than the usual shallow clone.
/// with C's allocator API, rather than the usual shallow clone.
fn clone(&self) -> CString {
let len = self.len() + 1;
let buf = unsafe { malloc_raw(len) } as *mut libc::c_char;
@ -136,8 +136,9 @@ impl<S: hash::Writer> hash::Hash<S> for CString {
}
impl CString {
/// Create a C String from a pointer, with memory managed by libc's malloc,
/// so do not call it with a pointer allocated by jemalloc.
/// Create a C String from a pointer, with memory managed by C's allocator
/// API, so do not call it with a pointer to memory managed by Rust's
/// allocator API.
///
///# Failure
///