|
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