A loop inside a function
Consider `int sum(int n) { int total = 0; for (int i = 0; i < n; ++i) { total += i; } return total; }`. The parameter `n` is visible throughout the function body. `total` is visible from its declaration to the closing brace of that body. `i` is visible within the `for` construct, but not after it. section 2.2
A scope is the part of a C program where an identifier is visible. A declaration is bound to the scope in which it appears: visibility begins at the declaration, not automatically at the start of the enclosing block. An identifier declared outside any compound statement, such as a function name, is visible from its declaration to the end of the file. Consistent declarations of an identifier can be repeated; contradictory declarations in the same scope are generally not allowed. section 2.2
TAKEAWAY: Braces around a structure declaration do not create a separate scope for a structure tag declared inside them. In the example below, `struct stardate` has the same visibility as `struct person`. If both are declared inside a function body, that surrounding compound statement limits their visibility. section 6.3.3
struct person {
char name[256];
struct stardate {
struct tm date;
struct timespec precision;
} bdate;
};
The nested `struct stardate` declaration illustrates why structural nesting must not be mistaken for a new scope. section 6.3.3
Scope and object lifetime answer different questions: where a name is visible, and whether an object still exists. A compound literal created in a `while` statement’s secondary block has a new instance on each iteration. Saving its address does not keep that instance alive after the loop; dereferencing the saved pointer afterward is invalid. In the contrasting `goto` example, the compound literal belongs to the surrounding block and remains alive until that block is left. section 19.3
TAKEAWAY: Do not use visibility alone to decide whether an object can be accessed. A pointer may remain visible after the object it points to has ceased to exist. Likewise, each function call has its own copy of local variables; sharing a function definition does not make those local objects one shared instance. section 19.3 section 7.4
