Errata

The function `parse_pair` has a bug. Indices on Strings in Rust correspond to byte offsets, but the String data is stored as UTF8. Thus, some characters are more than one byte. Indexing to a non-character boundary will panic (abort the program).

The code uses `&s[index+1..]`. It should instead use `&s[index + separator.len_utf8()]`.

This bug came up in an online Rust users forum:
https://users.rust-lang.org/t/something-wrong-in-function/51847

I am not an owner of the book and there is a language barrier at play, so please note that I am uncertain which formats have the bug / which format corresponds to page 42.

Note from the Author or Editor:
Thanks for pointing this out. It's true that the function will panic if `separator` is not an ASCII character. I think I'd rather document that restriction than complicate the code.

trait WriteHtml {
fn write_html(&mut self, &HtmlDocument) -> io::Result<()>;
}

I think the code above should've been written like this:

/// Trait for values to which you can send HTML.
trait WriteHtml {
fn write_html(&mut self, html: &HtmlDocument) -> io::Result<()>;
}

Note from the Author or Editor:
Fixed in current text. No further changes needed.

The book states: "After calling `read`, you must treat `*src` as uninitialized memory." However, the Rust language documentation says that `read` "leaves the memory in `src` unchanged" (see https://doc.rust-lang.org/std/ptr/fn.read.html).

It is not clear that `read` has any special "magic" causing the read-from memory to be treated as uninitialized. (For instance, reading from a type that implements `Drop` doesn't prevent that value from being dropped: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=e99b12f481d74340fbfd13b9580f94d2 )

Note from the Author or Editor:
The text is not entirely correct. It's true that, in general, `std::ptr::read` should be treated as leaving the source uninitialized, but if the referent type is `Copy`, this is not true.

However, the text probably needs to be clarified. The reader was left with the impression that the book believes `std::ptr::read` modifies the memory somehow (it does not), and from their phrasing ("causing ... to be treated") I'm guessing that it wasn't clear that it's the *programmer* who must treat the memory as uninitialized, and that Rust itself isn't treating it any differently.

Will fix in 2nd edition. Filed as issue #424.

Wrong, currently in print: String implements AsRef<&str>
Correct: String implements AsRef<str>

Note from the Author or Editor:
Fixed in 1st and 2nd edition.

In the code snippet, in the HTML of the page being served, both the inputs have name "n". That seems to be a typo. Input's name is used to refer to the element and its value; two inputs on the form having the same name is a bug. Also, the gcd function written earlier has two parameters named n and m, so it only makes sense for the inputs to have the same names: n and m.

Note from the Author or Editor:
Although this use of <input> names is contrary to recommended practice on the web, the doubled name is deliberate, the program actually does work as written, and the code is shorter because of it. However, many people have complained about it, so this section will probably need to be reworked anyway.

Filed as issue #420, to be fixed in 2nd edition.

On p50 it says floating point literals are inferred as f64 if both are possible. On p51 it then says
`println!("{}", (2.0).sqrt())` won't compile. These are contradictory. Both f32 and f64 are possible here, so it should infer f64 by the previous page's logic. Thus one of the pages is incorrect.

Moreover, this is reported as a bug against the compiler - see https://github.com/rust-lang/rust/issues/24124, which leads me to believe a compiler bug is being presented as expected, even logical, behaviour.

Note from the Author or Editor:
It's true that it's been reported as a bug, but no Rust team member has confirmed that it's unintended behavior. I think the text is just unclear as to why this doesn't work. I certainly didn't intend to present it as particularly logical.

Addressed in 2nd edition; won't fix in 1st.

In the figure both threads are named "thread 1", whereas the bottom one should be named "thread 2".

Note from the Author or Editor:
Confirmed: in Figure 19-5, the lower thread (horizontal blue bar) should be labeled "thread 2", not "thread 1".

Fixed in 1st and 2nd edition.

In this code example:

fn sort_by_statistic(cities: &mut Vec<City>, stat: Statistic {
cities.sort_by_key(|city| -city.get_statistic(stat));
}

and this similar one on the following page:

fn start_sorting_thread(mut cities: Vec<City>, stat: Statistic)
-> thread::JoinHandle<Vec<City>>
{
let key_fn = move |city: &City| -> i64 { -city.get_statistic(stat) };
thread::spawn(move || {
cities.sort_by_key(key_fn);
cities
})
}

regardless of how the "stat" variable is captured by the closure, it should be passed by reference
to city.get_statistic. I think this code could not pass the borrow checker unless Statistic was a
copyable type, but the context of these examples and the discussion on page 307 implies that
Statistic is not Copy.

Note from the Author or Editor:
Thank you for the report. Statistic was Copy in my head (my test code is like this: <https://gist.github.com/jorendorff/c04b6a2b56db051e0493de13acb77df0#file-closures-rs-L81-L86>) but you're right, the text then talks about the closure borrowing or gaining ownership of it, when for Copy types Rust would be happy to just copy the thing instead.

The easiest fix is to make Statistic non-Copy and fix up all the code. Better, rework the example, replacing Statistic with something concrete enough that readers can intuitively guess it's not Copy.

Will fix in 2nd edition, but not 1st.

The correct return type of split_last() is Option<(&T, &[T])>, and not Option<(&[T], &T)> that's in the book.

Note from the Author or Editor:
The reader is correct. This is fixed in the first and second editions.

5 8 in the figure should be 8 5, since they are capacity and length.

'If you omit the _marker field, Rust ...'

'_marker' should be 'behaves_like'.

Note from the Author or Editor:
Fixed on master.

' How should Rust know that any restrictions apply to pab’s lifetime?'

'pab' should be 'ptr_and_bit'.

Note from the Author or Editor:
Fixed on master.

'This feature supports extending the #[derive] attribute to handle custom traits, as shown in Figure 20-4.'


'custom traits' should be 'custom derives'.

Note from the Author or Editor:
Fixed on master.

'Multi-producer Channels Using Mutexes'


'Multi-producer' should be 'Multi-consumer'

Note from the Author or Editor:
Fixed on master.

"The nub of the problem is that sometimes the return value of `name` should be..."


The function name is 'get_name', not 'name'.

Note from the Author or Editor:
Fixed on master.

'as do the functions like [T]::binary_search.'

I seems that binary_search method is not using Borrow Trait.

https://doc.rust-lang.org/std/primitive.slice.html#method.binary_search

Note from the Author or Editor:
Fixed on master.

'as we did for the `Complex` type earlier in the book:'

I could not find the same code in other sections.

Note from the Author or Editor:
Fixed on master.

'Dark gray regions are unused.'

There are no 'dark gray regions' in Fig. 16-5.

And, the diagram shown in 16-5 is quite different from typical hash table implementation. I believe some more explanation is required.

'And like collect, you’ll need to specify the return type: the preceding example writes out the type of living and nonliving, and lets type inference choose the right type parameters for the call.'

The type of 'nonliving' is not wrote out in the code. I think this is confusing.

Note from the Author or Editor:
Fixed on master.

code fragment

where Rhs: ?Sized

this does not appear in the previous code.
In p.272, we have

trait PartialEq<Rhs: ?Sized = Self> {

instead.

Note from the Author or Editor:
Fixed on master.

The pattern in fig 10-7 seems to have a typo: "&Point3d { x, y, x }" should be "&Point3d { x, y, z }".

The "Floating point" section within chapter 3 has a possible error.

If the intention of the following statement:

assert_eq!(-1.01f64.floor(), -1.0);

is supposed to yield true, then the 2nd argument should be -2.0.

Note from the Author or Editor:
Fixed on master.

The Cargo.toml section used for the command line "cargo build" is [profile.dev] instead of [profile.debug]

Note from the Author or Editor:
Fixed on master.

File& operator=(const File &rhs) {
close(descriptor);
descriptor = dup(rhs.descriptor);
}

The operator must return *this:

File& operator=(const File &rhs) {
close(descriptor);
descriptor = dup(rhs.descriptor);
return *this;
}

Note from the Author or Editor:
Reader is correct. We will fix in HTML.

let parenthetical = "(".to_string() + string + ")";

will produce: expected &str, found struct `std::string::String`

It should instead be: let parenthetical = "(".to_string() + &string + ")";

Note from the Author or Editor:
Fixed on master.

Current. These do not parse because of the capital B. After fixing that, the first assertion still fails because it is a capital E instead of a lowercase one.

assert_eq!(bytes.iter().rposition(|&c| c == B'E'), Some(4));
assert_eq!(bytes.iter().rposition(|&c| c == B'X'), Some(0));

Expected (lowercasing, as appropriate, and now these assertions work):

assert_eq!(bytes.iter().rposition(|&c| c == b'e'), Some(4));
assert_eq!(bytes.iter().rposition(|&c| c == b'X'), Some(0));

Note from the Author or Editor:
In Chapter 15, the two code examples in the section "position, rposition, and ExactSizeIterator" are incorrect on Safari, but correct in the PDF and MOBI. The letters in single quotes, and the 'b' in front of them should be as follows:
'e', not 'E'
'z', not 'Z'
b'e', not B'E'
b'X' (this one is correct)

But, making Safari accurately reflect the contents of the Atlas HTML should correct this.

'E' is used, but it appears 'e' was intended.

Current (this assertion fails):

assert_eq!(text.chars().position(|c| c == 'E'), Some(1));

Expected (this assertion succeeds):

assert_eq!(text.chars().position(|c| c == 'e'), Some(1));

Note from the Author or Editor:
Safari is corrupting code examples by capitalizing text at random.

Figure 17-1. The UTF-8 encoding in the Code Point Represented column, third row the value should be 0xxxxyyyyyyzzzzzz, instead of the current 0xxxyyyyyyzzzzzz which is missing an x.

The statement "All of Rust’s numeric types implement std:: ops:: Neg, for the unary negation operator -;" probably is incorrect. My understanding is that the unary negation operator is implemented only for signed types, and that it is not implemented for the unsigned integer types u8, u16, u32, u64, u128, and usize because these types cannot represent negative numbers.

Note from the Author or Editor:
This is at the top of page 269 in my copy. "All of Rust's numeric types" should read "All of Rust's signed numeric types".

The book says: "There's a problem: a File has to be mut".

The type shared-reference-to-File implements Read/Write, so it does not need to be mutable to be used for reading or writing. It is not obvious or elegant, but it works.

Note from the Author or Editor:
The reader is correct, but the information he's citing is so obscure that I don't think this will affect the effectiveness of the explanation in the book in practice. (If you know enough to notice the problem the reader pointed out, you definitely don't need to read that part of the book.)

Since fixing this will require a significant rephrasing of the section, we'll leave this for a second edition.

let mut buffer = vec![0u8; 1024]; // 1024 zeroed-out bytes
The variable name 'buffer' in the above code snippet doesn't match the one in figure 16-1 which uses 'buf' instead.

Note from the Author or Editor:
In Figure 16-1, at the top right, "buf" should be changed to "buffer".

reader.read_to_end returns type of io::Result<usize> rather than io::Result<()>.

Note from the Author or Editor:
The sentence "Returns io::Result<()>." should be changed to: "Returns an `io::Result<usize>`, the number of bytes read."

let args = std::env::args().collect::<String>();
->
let args = std::env::args().collect::<Vec<String>>();

Note from the Author or Editor:
That's right: near the top of page 353, the line that reads

let args = std::env::args().collect::<String>();

should read

let args = std::env::args().collect::<Vec<String>>();

This portion should be made clearer, the text reads "So after initializing t, the program’s memory looks like this:" However, the program's memory will never 'look like' anything--as noted in a later paragraph, the program fails to compile. This should be addressed with some comment earlier. Perhaps, after showing the 'equivalent' Rust code, saying something like, "Now, for reasons we will explain for a moment, this code will fail to compile if you're typing it in yourself. However, let's imagine that we could get this code to compile and run..."

Note from the Author or Editor:
The text is okay as it stands; the reader doesn't like the flow we chose. I'll look this over if we do a second edition.