Skip to content

Commit

Permalink
clarify ffi C string nul term & length discussion
Browse files Browse the repository at this point in the history
re-written the paragraph, including:
 - Changed use of "calculated" to "count". "calculated" just sounds
   wrong, giving a false impression of what strlen() does.
 - Changed "C code must manually call a function". Firstly, "manually"?
   Secondly, a function is called in Rust also... the difference is in
   what the function does - counting v.s. reading an attribute...
  • Loading branch information
jnqnfe committed Dec 12, 2018
1 parent bd47d68 commit 85c6548
Showing 1 changed file with 9 additions and 12 deletions.
21 changes: 9 additions & 12 deletions src/libstd/ffi/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -45,18 +45,15 @@
//!
//! * **Nul terminators and implicit string lengths** - Often, C
//! strings are nul-terminated, i.e., they have a `\0` character at the
//! end. The length of a string buffer is not stored, but has to be
//! calculated; to compute the length of a string, C code must
//! manually call a function like `strlen()` for `char`-based strings,
//! or `wcslen()` for `wchar_t`-based ones. Those functions return
//! the number of characters in the string excluding the nul
//! terminator, so the buffer length is really `len+1` characters.
//! Rust strings don't have a nul terminator; their length is always
//! stored and does not need to be calculated. While in Rust
//! accessing a string's length is a O(1) operation (because the
//! length is stored); in C it is an O(length) operation because the
//! length needs to be computed by scanning the string for the nul
//! terminator.
//! end. The length of the string is not stored, but has to be determined
//! by scanning through the bytes of the string, looking for the
//! nul that marks its end, counting as it goes. The value returned by
//! common functions that perform this, is effectively the index position
//! of the nul, and thus the string length (in terms of buffer size) is
//! actually len+1. Rust strings don't have a nul terminator, their
//! length is always stored. As such, in Rust, accessing a string's
//! length is an O(1) operation; while in C, it is an O(length)
//! operation.
//!
//! * **Internal nul characters** - When C strings have a nul
//! terminator character, this usually means that they cannot have nul
Expand Down

0 comments on commit 85c6548

Please sign in to comment.