Skip to content

Commit 85c6548

Browse files
committed
clarify ffi C string nul term & length discussion
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...
1 parent bd47d68 commit 85c6548

File tree

1 file changed

+9
-12
lines changed

1 file changed

+9
-12
lines changed

src/libstd/ffi/mod.rs

+9-12
Original file line numberDiff line numberDiff line change
@@ -45,18 +45,15 @@
4545
//!
4646
//! * **Nul terminators and implicit string lengths** - Often, C
4747
//! strings are nul-terminated, i.e., they have a `\0` character at the
48-
//! end. The length of a string buffer is not stored, but has to be
49-
//! calculated; to compute the length of a string, C code must
50-
//! manually call a function like `strlen()` for `char`-based strings,
51-
//! or `wcslen()` for `wchar_t`-based ones. Those functions return
52-
//! the number of characters in the string excluding the nul
53-
//! terminator, so the buffer length is really `len+1` characters.
54-
//! Rust strings don't have a nul terminator; their length is always
55-
//! stored and does not need to be calculated. While in Rust
56-
//! accessing a string's length is a O(1) operation (because the
57-
//! length is stored); in C it is an O(length) operation because the
58-
//! length needs to be computed by scanning the string for the nul
59-
//! terminator.
48+
//! end. The length of the string is not stored, but has to be determined
49+
//! by scanning through the bytes of the string, looking for the
50+
//! nul that marks its end, counting as it goes. The value returned by
51+
//! common functions that perform this, is effectively the index position
52+
//! of the nul, and thus the string length (in terms of buffer size) is
53+
//! actually len+1. Rust strings don't have a nul terminator, their
54+
//! length is always stored. As such, in Rust, accessing a string's
55+
//! length is an O(1) operation; while in C, it is an O(length)
56+
//! operation.
6057
//!
6158
//! * **Internal nul characters** - When C strings have a nul
6259
//! terminator character, this usually means that they cannot have nul

0 commit comments

Comments
 (0)