From 50d179d0016ea5f3a3c820a45cdaa6921f9fb14c Mon Sep 17 00:00:00 2001 From: gamazeps Date: Thu, 18 Sep 2014 14:16:26 +0200 Subject: [PATCH] Doc says to avoid mixing allocator instead of forbiding it --- src/librustrt/c_str.rs | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/librustrt/c_str.rs b/src/librustrt/c_str.rs index cbf97c6ca2040..04a4e96ecc40e 100644 --- a/src/librustrt/c_str.rs +++ b/src/librustrt/c_str.rs @@ -38,8 +38,9 @@ unnecessary amounts of allocations. 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. +That means that the CString pointers should be freed with C allocator API +if you intend to do that on your own, as the behaviour if you free them with +Rust's allocator API is not well defined An example of creating and using a C string would be: @@ -137,8 +138,8 @@ impl hash::Hash for CString { impl CString { /// 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. + /// API, so avoid calling it with a pointer to memory managed by Rust's + /// allocator API, as the behaviour would not be well defined. /// ///# Failure /// @@ -272,7 +273,7 @@ impl CString { /// forgotten, meaning that the backing allocation of this /// `CString` is not automatically freed if it owns the /// allocation. In this case, a user of `.unwrap()` should ensure - /// the allocation is freed, to avoid leaking memory. You have to + /// the allocation is freed, to avoid leaking memory. You should /// use libc's memory allocator in this case. /// /// Prefer `.as_ptr()` when just retrieving a pointer to the