Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discrepancy in storage slot calculation for array of structs, or not? #216

Open
0xScratch opened this issue Feb 23, 2025 · 0 comments
Open

Comments

@0xScratch
Copy link

0xScratch commented Feb 23, 2025

Tags: @naddison36 @Nabeel-javaid

I was using sol2uml to calculate the storage slots of the Store contract (code below), which can also be found here. This contract is straightforward, with a payments struct, some storage variables, etc. The part that requires our focus is the array of structs topPayments.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

contract Store {

    struct payments {
        bool valid;
        uint256 amount;
        address sender;
        uint8 paymentType;
        uint256 finalAmount;
        address receiver;
        uint256 initialAmount;
        bool checked;
    }
    uint8 index;
    uint256 public number;
    bool flag1;
    address admin;
    mapping (address=>uint256) balances;
    bool flag2;
    address admin2;
    bool flag3;
    payments[8] topPayments;


    constructor(){

    }


    function setNumber(uint256 newNumber) public {
        number = newNumber;
    }

    function increment() public {
        number++;
    }
}

After creating a .svg for this contract using sol2uml. We get this:

Image

As you can see, topPayments takes 1792 bytes, which is correct since each payment struct covers 7 slots, equivalent to 224 bytes each. Thus, 224 * 8 = 1792 bytes, fairly simple. But as we move to the next step and spot this:

Image

Here 4 struct elements are represented individually and allotted 224 bytes, there's no doubt in that. But the rest 4 (in the middle) are actually allotted 928 bytes which seems quite inappropriate as 224 * 4 = 896 bytes. Due to this, the whole summation becomes 1824 bytes (896 + 928).

And, we can clearly see 1792 != 1824, which makes me assume either sol2uml is wrong here or there's something that I missed in this scenario.

Hope you guys can help me out...

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant