Symbol Table Management Questions and Answers

Answer: A

Correct answer: looking the name up in the current scope before installing it

Only the current scope is searched, because a declaration in an enclosing scope is legitimately shadowed rather than duplicated. That single lookup before installation is what distinguishes an error from ordinary nesting, and it is why the check must happen at declaration rather than afterwards.

Answer: B

The two operations differ precisely in how far they search. Requiring the duplicate check to search outward would wrongly reject any legitimate shadowing declaration. Almost every block structured program relies on shadowing somewhere.

Answer: C

The storage class determines where the variable lives and how long it persists. Code generation needs it to decide between a static address and a stack offset. The class also determines whether the variable survives between calls.

Answer: D

Locals live in the activation record created on each call, so their addresses are relative to a frame pointer. Only globals can be given an address fixed at compile time. Recursion is precisely why a local cannot have a fixed address.

Answer: A

Import and export lists determine which names cross module boundaries. The compiler records what it exports so a separate compilation of another module can check the uses. That record is what an interface or header file makes available.

Answer: B

The linker needs exported definitions and imported references to connect modules. Local names are irrelevant to it, though they may be kept separately for a debugger. Keeping them in a separate section allows a binary to be stripped later.

Answer: C

A debugger must map machine addresses back to source names. The information is derived from the symbol table but written in a separate standard format the debugger understands. The format must describe types, scopes and locations independently of the compiler.

Answer: D

Both are true and the reason gives the mechanism, and it explains why stripped binaries are hard to debug. Optimisation complicates matters further, since a variable may live in different places at different points or nowhere at all.

Answer: A

Correct answer: a variable may have no single storage location during its lifetime

Optimisation moves values between registers and memory, keeps them in different registers at different points, and may eliminate a variable entirely by folding or propagating it. A debugger asking where a variable is may find several answers or none, which is why debugging optimised code is difficult and why compilers emit location lists rather than single addresses.

Answer: B

Header files or module interfaces supply the shared declarations. When two modules disagree, the mismatch may not surface until link time or, worse, until run time. Shared interface files are the usual way of preventing such disagreements.