Document that CStrings live in the libc heap

Closes issue #17067 and improves pr #17355

src/librustrt/c_str.rs

@@ -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
     ///