Why do arrays declared within functions reference storage point 0 by default?

Question

According to the Solidity Documentation, for the following code,

". . . the compiler interprets x as a storage pointer and will make it point to the storage slot 0 by default. This has the effect that someVariable (which resides at storage slot 0) is modified by x.push(2)".

/// THIS CONTRACT CONTAINS AN ERROR
pragma solidity ^0.4.0;

contract C {
    uint someVariable;
    uint[] data;

    function f() public {
        uint[] x;
        x.push(2);
        data = x;
    }
}

In another post, user smarx pointed out that:

"When you declare a storage variable, it's essentially a reference to some location in storage. Until you assign it to something, it points to location 0, which also happens to be the location of the first declared state variable (in this case a). You're basically using an uninitialized pointer".

What confuses me, however, is that if "uint [] x" points to 0, where "someVariable" resides, wouldn't "uint[] data" do the same? Aren't both of these arrays uninitialized? If "data" occupies slot 1, wouldn't "x" just occupy slot 2?

My guess is that when it is within a function, it starts from 0 again, assuming that everything will be saved to memory, but then I would expect an array declared within a function to reference memory by default.

Answer 1

What confuses me, however, is that if uint [] x points to 0, where someVariable resides, wouldn't uint[] data do the same?

No, data would points to the location 1.

Aren't both of these arrays uninitialized?

yes, but the second one is pointing to an uninitialized storage location which is 0 by default (since storage is not dynamically allocated). As per doc:

The type of the local variable x is uint[] storage, but since storage is not dynamically allocated, it has to be assigned from a state variable before it can be used. So no space in storage will be allocated for x, but instead it functions only as an alias for a pre-existing variable in storage.

.

If data occupies slot 1, wouldn't x just occupy slot 3?

No, since is not allocated dynamically. But if would be allocated dynamically its reference will be stored in the slot 2 not 3.