How big a number can get

Chatterbox's messages_seen goes up by one for every message. On paper you can always add one more. In a computer you cannot, and the reason is how a number is stored.

Memory is made of bits. A bit is one tiny switch that is either off or on, written 0 or 1. One bit can tell two things apart. Two bits make four patterns (00, 01, 10, 11), three bits make eight, and every extra bit doubles the count. Eight bits together are a byte, the unit memory is measured in, and a byte has 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 = 256 patterns.

A whole number is stored as one of those patterns. So a number kept in one byte can be one of exactly 256 values, and if it is never negative, those are 0 to 255. There is no 257th pattern for 256. Guess what Rust says is the largest number that fits:

Rust has a whole family of whole-number types, and the name of each one tells you two things. The letter says whether it can be negative: u for unsigned (no minus sign, never negative) and i for integer, which here means one that can be negative too. The number says how many bits it uses. So u8 is 8 bits, never negative; i32 is 32 bits (4 bytes), positive or negative.

A type that allows negatives does not get more patterns, so it shares them out: half below zero and half from zero up. That is why i8 runs from −128 to 127 instead of 0 to 255.

The odd one out is usize, which you met in lesson 2.3 as the type for lengths and counts. Its size is not fixed by its name: it is as big as the computer's memory addresses (an address is the number the computer uses to find one spot in its memory, like a house number on a very long street; chapter 4 draws the picture), so 8 bytes on a 64-bit computer (nearly every laptop and phone today) and 4 bytes on a 32-bit one. That is exactly why Rust uses it for lengths and positions: the length of anything in memory can never be bigger than the memory can count. (isize is its negative-allowed twin, and you will rarely need it.)

So which do you pick? i32 is the everyday default, and Rust chooses it for a bare whole number. usize for lengths and positions. A u type for anything that can never be negative, sized to the biggest value you will ever need. Bigger types cost more memory, but only a few bytes each; running out of room costs a lot more. Open each type below: the sizes are measured with this compiler, not copied from a book.

So what happens when a u8 already holding 255 is asked to add one more? The true answer, 256, has no pattern. Try it.

That is what you will see while you work, and it is the useful reaction: the program stops at the exact line, instead of carrying on with a count that is wrong. Rust counts overflow as a mistake. The real fix is a type big enough that it never happens, and for the rare case where the edge is real, the next section shows how to say what you want there.

There are two other reactions, one earlier and one later, folded away below for when you are curious: the compiler refusing an overflow it can see on the page, and a build made for shipping quietly wrapping around to 0.

fn main() {
    let messages_seen: u8 = 255 + 1;
    println!("messages so far: {}", messages_seen);
}

error: this arithmetic operation will overflow
 --> src/main.rs:2:29
  |
2 |     let messages_seen: u8 = 255 + 1;
  |                             ^^^^^^^ attempt to compute `u8::MAX + 1_u8`, which would overflow
  |
  = note: `#[deny(arithmetic_overflow)]` on by default

fn main() {
    let mut messages_seen: u8 = 254;
    messages_seen += 1;
    println!("messages so far: {}", messages_seen);
    messages_seen += 1;
    println!("messages so far: {}", messages_seen);
}

$ cargo run
   Compiling counter v0.1.0 (~/counter)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.36s
     Running `target/debug/counter`
messages so far: 255

thread 'main' (92428561) panicked at src/main.rs:5:5:
attempt to add with overflow
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

$ cargo run --release
   Compiling counter v0.1.0 (~/counter)
    Finished `release` profile [optimized] target(s) in 0.17s
     Running `target/release/counter`
messages so far: 255
messages so far: 0

Sometimes the edge is real and expected, and then you should say what you want instead of leaving it to the build. Each whole-number type comes with functions for exactly that. u8::saturating_add(a, b) adds, but stops at the top: past 255 it simply stays at 255. u8::wrapping_add(a, b) wraps around on purpose: past 255 it starts again from 0. A third, checked_add, answers "there is no answer" instead of giving a number; that kind of answer gets its own lesson in chapter 5. You will usually see these written with a dot, as count.saturating_add(10); the dot form arrives in the next lesson, and both mean the same thing.

$ cargo run
255
4

Until now messages_seen had no type written down, so Rust picked i32 for it. That works, but it says the wrong thing: a count of messages can never be negative. The new line makes it a u32: never negative, four bytes, and able to reach 4,294,967,295. Sending one message a second without sleeping, that is more than 136 years of chatting, so the counter will not run out. A u8 would run out after 255 messages, which is one busy afternoon.

The green lines are the type, let mut messages_seen: u32 = 0;, and a comment above it saying why. Nothing else changes: messages_seen += 1; still adds one, and the run still ends with messages so far: 1.

Chatterbox v0.2
Hi Sam! I'm Chatterbox.
Type a message and I will answer.
(limit: 200 bytes a message, quiet: false)
messages so far: 1

Sources The Rust Book: data types (integer types and integer overflow) · The Rust Reference: numeric types · Rust standard library: u8 (MAX, saturating_add, wrapping_add, checked_add) · rustc lints: deny-by-default (arithmetic_overflow)