From f90c88a34ae9261c08ddb306658566b8377360b1 Mon Sep 17 00:00:00 2001 From: Nithin Chandran P Date: Sun, 18 Jun 2023 10:29:17 +0530 Subject: [PATCH] Typo fixed --- L6-Delegate-Call.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/L6-Delegate-Call.md b/L6-Delegate-Call.md index 620b940..2114379 100644 --- a/L6-Delegate-Call.md +++ b/L6-Delegate-Call.md @@ -74,7 +74,7 @@ The actual addition part is not that interesting, what's interesting is that the -You know from the previous lessons that each variable slot in solidity is of 32 bytes which is 256 bits. And when we used `.delegatecall()` from `Student` to `Calculator` we used the storage of `Student` and not of `Calculator` but the problem is that even though we are using the storage of `Student`, the slot numbers are based on the calculator contract and in this case when you assign a value to `result` in the `add` function of `Calculator.sol`, you are actually assigning the value to `mySum` which in the student contract. +You know from the previous lessons that each variable slot in solidity is of 32 bytes which is 256 bits. And when we used `.delegatecall()` from `Student` to `Calculator` we used the storage of `Student` and not of `Calculator` but the problem is that even though we are using the storage of `Student`, the slot numbers are based on the calculator contract and in this case when you assign a value to `result` in the `add` function of `Calculator.sol`, you are actually assigning the value to `mySum` which is in the student contract. This can be problematic, because storage slots can have variables of different data types. What if the `Student` contract instead had values defined in this order?