Questions: Scope, Shadowing, and Variable Lifetime

Question 1

A global variable count = 10 exists. Inside a function, you write count = 0 (declaring a new local variable with the same name). After the function runs, what is the value of the global count?

• A. 0 — the function modified the global variable
• B. 10 — the function created a shadow variable; the global was unaffected
• C. Undefined — the global was destroyed when the function ran
• D. 0 — inner scope variables always update the outer scope version

Answer: (B)

Shadowing creates a completely new, independent variable in the inner scope that happens to share the same name as the outer one. Modifying the shadow does NOT affect the original. The global count = 10 survives the function call unchanged. Option A is the classic bug that shadowing causes — programmers mistakenly believe they are modifying the outer variable when they are only modifying a local shadow.

Question 2

Consider a variable x declared inside an if-block in a language with block scope. After the if-block ends, which statement is correct?

• A. x is still accessible but its value is undefined
• B. x no longer exists — both its scope and lifetime have ended
• C. x still exists in memory but cannot be accessed by name
• D. x is accessible only from the enclosing function, not globally

Answer: (B)

For a local variable declared inside a block, both scope (visibility) and lifetime (memory existence) end when the block ends. The variable is both inaccessible AND destroyed. Option A is wrong — the language does not merely make the value undefined, the name binding ceases to exist. Option C conflates scope with lifetime — for stack-allocated locals, both end together. Option D describes the behavior of a function-scoped variable, not a block-scoped one.

Question 3

A variable's scope and its lifetime are generally identical — they both start and end at the same points in program execution.

• T. True
• F. False

Answer: False

Scope and lifetime can diverge. In garbage-collected languages, an object's lifetime can extend beyond the scope of the variable that created it — as long as other references to it exist, the object persists. Conversely, in C, returning a pointer to a local variable creates a situation where the pointer variable (in the caller) is in scope, but the object it references has been destroyed (its lifetime ended when the callee returned). These are classic examples of scope-lifetime divergence.

Question 4

In languages with lexical (static) scoping, an inner scope can read variables from all enclosing outer scopes unless shadowed.

• T. True
• F. False

Answer: True

Lexical scoping defines the scope hierarchy based on where code is written: inner scopes can see all names in their enclosing scopes unless a shadow hides them. This is the standard model in most languages (C, Java, Python, JavaScript). The inner scope 'inherits' visibility from all outer scopes, climbing the nesting hierarchy outward until a match is found. If a shadow exists at an inner scope level, that shadow is found first, preventing access to the outer variable by that name.

Question 5

Why is it important to distinguish between a variable's scope and its lifetime, and give a concrete example where they differ?

Model answer: Scope is the region of code where a variable's name is valid and can be used; lifetime is how long the variable's storage actually exists in memory. They differ when references outlive the original variable. Example: in Python, assigning obj = MyClass() creates a reference whose scope is the current block, but if obj is passed to another function or stored in a list, the object's lifetime extends as long as any reference to it exists. In C, returning a pointer to a stack-allocated local variable is the reverse: the pointer is in scope but points to destroyed storage.

This distinction matters for memory safety. In C/C++, using a pointer after the pointed-to variable's lifetime ends is undefined behavior (dangling pointer). In GC languages, objects can persist longer than expected, causing memory leaks if unintended references keep them alive. Scope tells you about name resolution; lifetime tells you about memory validity.