Uninitialized State Variables

Severity: Med ID: uninitialized-state

Flags state variables that are read anywhere in a contract's inheritance chain but never assigned. Because Solidity zero-initialises all storage, such a variable silently returns its type's zero value (0, address(0), false, etc.), which almost always indicates a missing initialisation step, for example, forgetting to set owner in the constructor.

What it does

For each non-constant, non-immutable state variable across the full C3-linearised inheritance chain, the lint checks whether it is ever written, via an inline initialiser at the declaration site, any assignment (including compound assignments such as +=), delete, pre/post increment/decrement, or push/pop on a dynamic array, anywhere in any function or constructor in the hierarchy, including modifier call arguments and base-constructor arguments. If the variable is read (in a function body, state-variable initialiser, modifier argument, or compiler-synthesised public getter) but never written by any of the above, it is flagged.

Assembly bail-out: if any function body in the inheritance chain contains inline assembly (which Solar lowers to an opaque AST node), the lint skips the entire contract conservatively to avoid false positives from untracked storage writes.

Known limitations:

• Storage aliases: Foo storage f = bar; f.x = 1; is not detected as a write to bar.
• Storage-parameter calls (partial): the lint detects when a state variable is passed as a storage reference to a bare, qualified, or super internal call and treats it as a write. What remains undetected are calls made through a local storage alias, or through a member expression where the receiver is itself a state variable.
• Member calls: any member call whose receiver is a state variable (e.g. oracle.latestAnswer(), token.balanceOf(address)) suppresses the warning for that variable. Without full call-graph resolution the lint conservatively treats the receiver as potentially mutated, to avoid false positives from push/pop and library-dispatch patterns (using Lib for T). Read-only interface calls on uninitialized variables will therefore not be flagged.

Why is this bad?

A variable that is always read as its zero default is almost certainly a logic bug. Common consequences include:

• Ownership checks that permanently pass or fail (owner is always address(0)).
• Token balances that always read as zero regardless of deposits.
• Flags and counters that never reflect actual contract state.

The Solidity compiler does not warn about this pattern because reading an uninitialized storage variable is syntactically valid.

Example

Bad

contract Escrow {
    address public owner; // never set, always address(0)

    function withdraw() external {
        require(msg.sender == owner, "not owner"); // always fails
        payable(owner).transfer(address(this).balance);
    }
}

Good

contract Escrow {
    address public owner;

    constructor(address _owner) {
        owner = _owner; // initialized in constructor
    }

    function withdraw() external {
        require(msg.sender == owner, "not owner");
        payable(owner).transfer(address(this).balance);
    }
}