Variables and Types

A C variable is not an abstraction — it is a name for some bytes, at a real address, with a type that tells the compiler how many bytes and how to interpret them. Every C concept from here to pointers builds on taking that literally.

Declaration

#include <stdbool.h>

int count = 42;          // 4 bytes, signed integer
double price = 9.99;     // 8 bytes, floating point
char grade = 'A';        // 1 byte (single quotes = one character)
bool paid = true;        // 1 byte, from <stdbool.h>

Type first, then name — and the type is a commitment about memory, not a hint. The core set:

• int — the default integer (32-bit on every platform you'll meet: ±2.1 billion)
• long long — 64-bit when you need the range
• double — the default floating type (float exists; it's less precise and buys you nothing here)
• char — one byte; both "tiny integer" and "text character," a dual identity that matters in the Strings lesson
• bool — true/false, but only after #include <stdbool.h>

That last one has history attached. C had no boolean type at all until C99, so decades of C — and plenty of code written this year — uses a plain int with 0 for false and anything non-zero for true. <stdbool.h> gives you the spelling bool / true / false over that same machinery (sizeof(bool) is 1, and printing one with %d shows 1 or 0). Both styles are idiomatic; bool says what you mean, and the int convention is why if (n) means "if n is non-zero" — which the Conditionals lesson leans on hard.

The uninitialized trap — C's first sharp edge

int x;
printf("%d\n", x);    // prints… whatever garbage was in those bytes

C does not zero your variables. A declared-but-unassigned local contains whatever the memory held before — often 0 in trivial tests (which is how the bug hides), then something else in production. This isn't an error, isn't a warning by default, and is the canonical C beginner bug. The rule that prevents it costs nothing: initialize at declaration, always. int x = 0; — done, bug class extinct. (gcc -Wall catches many cases; the habit catches all of them.)

Reading input: scanf and the &

int a, b;
scanf("%d %d", &a, &b);
printf("%d\n", a + b);

scanf is printf's inverse: a format string of specifiers (%d int, %lf double, %c char), then the variables to fill — each prefixed with &. That ampersand is your first pointer, three chapters early: it means "the address of a," because scanf needs to know where to put the value, not what it currently is. Forget the & and the program compiles (with a -Wall warning!) and then crashes or corrupts at runtime — the classic C failure signature: compiles fine, dies weird.

Good news for grader input: %d skips any whitespace — spaces, newlines, tabs — before the number. Inputs on one line or three lines parse identically. One asymmetry to pin now: scanf reads a double with %lf, but printf prints it with %f. It's inconsistent, it's historical, and it's on every C quiz ever written.

No implicit safety, some implicit conversion

C will mix numeric types silently — int + double promotes to double, and narrower types convert on assignment, losing data without complaint: int n = 3.99; compiles and n is 3 — truncated toward zero, not rounded, no warning by default. int m = 3.01; is also 3. Where Go and Rust force you to write the conversion, C assumes you meant it. The professional posture: make conversions explicit anyway — int n = (int)price; — so readers (and reviewers) see the truncation happen.

Your exercise: Sum Two Numbers

Read two integers, print the sum: declare, scanf("%d %d", &a, &b), printf("%d\n", a + b). Checklist that separates pass from flail: & on every scanf argument, and matching specifiers to types — %d for int. Using %d with a double isn't an error the compiler must stop; it's garbage output at runtime, found only by looking. Three lines of C, three chances to learn its personality.