I'm trying to understand how storage pointers work. From looking at the ethereumjs-vm implementation it seems that the actual value is returned from SLOAD. Does the compiler handle the 'pointer' functionality? (ie. calls SSTORE if its modified).
1 Answer
Yes, the compiler handles the pointer functionality. You do not need to explicitly de-reference a storage pointer when you want to write to or read from the storage location it points to.
I think the fact that they are called pointers is very confusing. It reminds me of C pointers, but storage pointers in Solidity are much more like C++ or PHP references than they are like C pointers.
Solidity pointers:
uint256[] public a;
constructor() public
{
a.push(1);
test(a);
}
function test(uint256[] storage b) private
{
b[0] = 7;
// a[0] is now 7
}
C++ references (similar to Solidity pointers):
int a = 1;
int& b = a;
b = 7;
// a is now 7
PHP references (also similar to Solidity pointers):
$a = 1;
$b = &$a;
$b = 7;
// a is now 7
C pointers (very different from Solidity pointers):
int a = 1;
int* b = &a;
b = 7;
// a is now still 1
-
"the fact that they are called pointers is very confusing" <-- Where do you see them being called pointers? I thought the Solidity documentation called them references. May 9, 2018 at 17:24
-
1@smarx Two excerpts from the Solidity documentation: "This is of course not the case if storage pointers are passed as function arguments as in the case for the high-level libraries." "Multi-dimensional memory arrays are pointers to memory arrays."– JesbusMay 9, 2018 at 17:26
-
Ugh. I agree that "references" is a much better term. Maybe a bug or pull request is in order. May 9, 2018 at 17:38