Skip to content

Correct use of 'nul' 'null' and capitalization in the book #34294

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

Merged
merged 2 commits into from
Jul 6, 2016
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions src/doc/book/ffi.md
Original file line number Diff line number Diff line change
Expand Up @@ -521,14 +521,14 @@ against `libc` and `libm` by default.

# The "nullable pointer optimization"

Certain types are defined to not be `null`. This includes references (`&T`,
Certain types are defined to not be NULL. This includes references (`&T`,
`&mut T`), boxes (`Box<T>`), and function pointers (`extern "abi" fn()`).
When interfacing with C, pointers that might be null are often used.
When interfacing with C, pointers that might be NULL are often used.
As a special case, a generic `enum` that contains exactly two variants, one of
which contains no data and the other containing a single field, is eligible
for the "nullable pointer optimization". When such an enum is instantiated
with one of the non-nullable types, it is represented as a single pointer,
and the non-data variant is represented as the null pointer. So
and the non-data variant is represented as the NULL pointer. So
`Option<extern "C" fn(c_int) -> c_int>` is how one represents a nullable
function pointer using the C ABI.

Expand Down
2 changes: 1 addition & 1 deletion src/doc/book/raw-pointers.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ Here are some things to remember about raw pointers that are different than
other pointer types. They:

- are not guaranteed to point to valid memory and are not even
guaranteed to be non-null (unlike both `Box` and `&`);
guaranteed to be non-NULL (unlike both `Box` and `&`);
- do not have any automatic clean-up, unlike `Box`, and so require
manual resource management;
- are plain-old-data, that is, they don't move ownership, again unlike
Expand Down
2 changes: 1 addition & 1 deletion src/doc/book/strings.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ strings also work differently than in some other systems languages, such as C.
Let’s dig into the details. A ‘string’ is a sequence of Unicode scalar values
encoded as a stream of UTF-8 bytes. All strings are guaranteed to be a valid
encoding of UTF-8 sequences. Additionally, unlike some systems languages,
strings are not null-terminated and can contain null bytes.
strings are not NUL-terminated and can contain NUL bytes.

Rust has two main types of strings: `&str` and `String`. Let’s talk about
`&str` first. These are called ‘string slices’. A string slice has a fixed
Expand Down
4 changes: 2 additions & 2 deletions src/doc/book/unsafe.md
Original file line number Diff line number Diff line change
Expand Up @@ -63,7 +63,7 @@ In addition, the following are all undefined behaviors in Rust, and must be
avoided, even when writing `unsafe` code:

* Data races
* Dereferencing a null/dangling raw pointer
* Dereferencing a NULL/dangling raw pointer
* Reads of [undef][undef] (uninitialized) memory
* Breaking the [pointer aliasing rules][aliasing] with raw pointers.
* `&mut T` and `&T` follow LLVM’s scoped [noalias][noalias] model, except if
Expand All @@ -77,7 +77,7 @@ avoided, even when writing `unsafe` code:
* Using `std::ptr::copy_nonoverlapping_memory` (`memcpy32`/`memcpy64`
intrinsics) on overlapping buffers
* Invalid values in primitive types, even in private fields/locals:
* Null/dangling references or boxes
* NULL/dangling references or boxes
* A value other than `false` (0) or `true` (1) in a `bool`
* A discriminant in an `enum` not included in its type definition
* A value in a `char` which is a surrogate or above `char::MAX`
Expand Down