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

int count = 42;          // 4 bytes, signed integer
double price = 9.99;     // 8 bytes, floating point
char grade = 'A';        // 1 byte (single quotes = one character)

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

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, not rounded, no warning by default). 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, \n in the printf, and matching specifiers to types (%d for int — %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.