Variable Shadowing Remediation

Overview

When a derived contract declares a state variable with the same name as one in a parent, Solidity allocates two separate storage slots. Inherited functions read the parent’s slot while functions in the derived contract read their own, so an update on one side is invisible to the other. The fix is to stop redeclaring the variable and use the inherited one.

Related Detector: Variable Shadowing

Recommended Fix

Before (Vulnerable)

contract Parent {
    address public owner;
    constructor() { owner = msg.sender; }
}

contract Child is Parent {
    address public owner; // Shadows Parent.owner — separate storage slot
}

After (Fixed)

contract Parent {
    address public owner;
    constructor() { owner = msg.sender; }
}

contract Child is Parent {
    // No redeclaration; Child uses the inherited Parent.owner.
}

With the redeclaration removed, both the constructor’s assignment and any access in the child resolve to a single storage slot. Invariants that assume one shared owner now hold.

Alternative Mitigations

If a separate value is genuinely required, give it a distinct, descriptive name so the two are never confused, and document why both exist.
Expose the parent value through super or an explicit getter when a derived function must read it, making the source of the value unambiguous.
Compile with a recent Solidity version; releases since 0.6.0 reject state-variable shadowing at compile time, so upgrading turns this class of bug into a build error.

Common Mistakes

Renaming the child variable but continuing to read the parent’s getter, which still returns the parent slot and not the renamed value.
Initializing the shadowing variable in the child constructor and assuming inherited modifiers (such as onlyOwner) will honor it — the modifier reads the parent slot.
Treating local-variable shadowing of a state variable as harmless; a function-local name that matches a state variable silently operates on the local copy.