Scope, Lifetime, and Storage Classes

The Chapter 2 Promise, Kept

Back in chapter 2 you memorized four storage classes on trust, because demonstrating them needed functions to enter twice and files to share. You have the functions now. This lesson turns the memorized table into working programs: where a name is visible (scope), how long its storage lives (lifetime), and the keywords that adjust both.

Scope: Where a Name Is Visible

A name declared inside a block has block scope: visible from its declaration to the block's closing brace, invisible outside. Each function's locals and parameters are its private world, which is why every function in this course can call its counter i without collision.

A name declared outside every function has file scope, visible from its declaration to the end of the file, a global:

Both functions touch the same callCount. Convenient, and precisely the problem: any function can modify a global, so reasoning about its value means reading the whole program, the local-reasoning cost that made goto infamous, now applied to data. Course rule, matching professional practice: globals only when several functions genuinely share one piece of state and passing it around would obscure more than it clarifies, and never as a way to dodge parameters. When a local shares a global's name, the local shadows it inside its block, a legal, warning-worthy trap exams enjoy.

Lifetime, and static Locals

Scope says where the name works; lifetime says when the storage exists. Automatic locals are born at block entry and die at exit, fresh each time. A static local keeps block scope, invisible outside its function, but gains program lifetime, initialized once and persisting between calls:

101, 102, 103: the chapter 2 claim, finally observable. The static int ticket = 100; initialization happens once, before the program starts, not on each call, the distinction that separates static from automatic in one line. Static storage is also zero-initialized without an initializer, as promised. A static local is a global's discipline done right: shared across calls but not across functions, persistent state with the smallest possible audience.

The Other Two Keywords

extern declares a name whose definition lives elsewhere, in another file of a multi-file program: extern int sharedTotal; promises the linker a definition exists somewhere. The platform's exercises are single-file, so extern remains described rather than demonstrated here; the headers lesson of chapter 10's neighborhood puts it to work when programs split across files, and its exam definition stands: declaration without definition, for cross-file sharing.

static at file scope is the same keyword's second, unrelated job: applied to a global or a function, it makes the name invisible to other files (internal linkage), the opposite direction from extern. One keyword, two meanings, disambiguated entirely by position, a favorite exam trick question. And register, the ignored hint, completes the historical set.

The Table, Now Earned

Chapter 2's version of this table was vocabulary; this one you can verify by running the programs above.

Key Takeaways

• Scope is where the name works: block scope for locals and parameters, file scope for globals; locals shadow same-named globals.
• Lifetime is when the storage exists: automatic locals die at block exit; static and file-scope storage lives the whole program, zero-initialized by default.
• static in a block means initialized once, persisting between calls: cross-call state with a one-function audience.
• static at file scope means hidden from other files; extern means defined in another file: one keyword, two jobs, told apart by position.
• Globals cost local reasoning; prefer parameters and returns, then static locals, and globals only for genuinely shared state.