|
45 | 45 | //!
|
46 | 46 | //! * **Nul terminators and implicit string lengths** - Often, C
|
47 | 47 | //! 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. |
60 | 57 | //!
|
61 | 58 | //! * **Internal nul characters** - When C strings have a nul
|
62 | 59 | //! terminator character, this usually means that they cannot have nul
|
|
0 commit comments