From 565474aadda4d2b866396f87df1626a0a63f80f0 Mon Sep 17 00:00:00 2001 From: Alexander Merritt Date: Wed, 15 Jun 2016 22:37:39 -0400 Subject: [PATCH] Correct use of 'nul' 'null' and capitalization r? @steveklabnik --- src/doc/book/ffi.md | 6 +++--- src/doc/book/raw-pointers.md | 2 +- src/doc/book/strings.md | 2 +- src/doc/book/unsafe.md | 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/doc/book/ffi.md b/src/doc/book/ffi.md index f48e87c4224..7fb5df3b7a9 100644 --- a/src/doc/book/ffi.md +++ b/src/doc/book/ffi.md @@ -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`), 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 c_int>` is how one represents a nullable function pointer using the C ABI. diff --git a/src/doc/book/raw-pointers.md b/src/doc/book/raw-pointers.md index 679f5489ea8..ae100aec3b5 100644 --- a/src/doc/book/raw-pointers.md +++ b/src/doc/book/raw-pointers.md @@ -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 diff --git a/src/doc/book/strings.md b/src/doc/book/strings.md index 7be90e785b0..135778c38b5 100644 --- a/src/doc/book/strings.md +++ b/src/doc/book/strings.md @@ -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 diff --git a/src/doc/book/unsafe.md b/src/doc/book/unsafe.md index af4e351569f..9cab586b82c 100644 --- a/src/doc/book/unsafe.md +++ b/src/doc/book/unsafe.md @@ -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 @@ -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`