-
Notifications
You must be signed in to change notification settings - Fork 13.3k
[std] clarify ffi C string nul term & length discussion #56140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Part of me wants to add some types to single out what "Rust strings" actually means. Something like:
On the other hand, there are many more "string" types in Rust, and e.g. |
||
//! 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 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like "calculated" is still a better word here? "Determined" feels like it implies that there's some kind of conceptual decision-making going on, but "calculated" feels more like it's a rote procedure that needs to be run through to figure out the length. I could be reading way too far into this, though.
>_>