i have a contract that receives a call to a different contract, does some checks, and needs to pass some more data to that other contract (in addition to the data it received). my current plan is to just append that data (has constant length) to the calldata i receive for that other contract, and then in the other contract slice off the last few bytes of the calldata

if this works w/o problems, it makes me wonder why arguments of functions whose parameters are all constant length are not simply packed-encoded to save those extra bytes

unfortunately changing the ABI is a huge effort that would need to be coordinated across the ecosystem

also note that the EVM is a 256bit machine (i.e. each word is 32 bytes)

so sometimes less data means more operations

yes, i can see that it might make sense to waste a few bytes if it means that no variable is broken across two 32 byte words. this is why padding might make sense. but this logic breaks down for the last hunk of data

adding padding to the last bit of data never avoids a break of a variable into two 32 byte words. that break wouldn't happen anyway

i also don't see how it even would line up nicely. shouldn't that 4 bytes in the beginning (for the function selector) throw the whole alignment off?

i think that most people agree that the abi is not ideal, just extremely hard to change

One of ethereum's million clones could pull it off. If you're making a new chain, you just need to adapt the tools, not somehow establish compatibility with a million pre-existing contracts

but your tools would soon get outdated

unless you are willing to fork maintain every fork

@alcuadrado can you please clarify this? Can the evm read at a byte level before loading stuff into the 32 byte slots?

That's how you show that your chain won't become deprecated soon ;)

If you can't maintain a few tools, you can't guarantee the longevity of a new chain

nop, it can't

well, as the author of the most popular tool, i'm fairly sure you are understimating the amount of time it takes 😂

Ooof, as a truffle user i had no idea who you were

I guess you're more informed

Then I'll try measuring how much gas it takes to read at different locations of calldata. Maybe I'll find a pattern

lol no worries

you can also look at the generated code

Never did that. I expected it to be equal except for the offsets if I'm going to access the calldata via solidity assembly. But I'll take a look. Thanks for the hint

Btw if anyone is interested in this, tell me. Then I'll check back with what I found. But i don't want to spam this group if no one is interested

Sure you can share.

I have tried the most popular tool in a new project now and I'm really impressed. Having types for the contracts and everything is really nice, and the speed that's possible with fixtures is just amazing (bet it'd be even better if fixtures allowed more than 2 layers of nesting ;) or whatever the current limitation is; haven't figured the out fully). Also: its nice to have a coverage tool that actually works. Thank you for this amazing tool. I shouldn't have wasted all that time with truffle

I'm glad you liked it @hallogutentag !

can you expand on the 2 layers of nesting thing?

It's a known limitation. There even is an error message saying that nested fixtures aren't supported. They are kind of supported, though. I've never had it fail on me with 2 layers of nesting. I.e. function foo() loads function bar() as a fixture and then some other function loads function foo() as a fixture. This always seems to work. But stack them one layer deeper, and most of the time it shows that error message about nested fixtures not being supported

I see

we'll add a guide explaining how to do that

Cool, thank you

but it's basically this:


async function oneFixture() {
// ...
return {a, b};
}

async function otherFixture() {
const {a, b} = await oneFixture();
// ...
return {a, b, c, d};
}

// ...

loadFixture(otherFixture);

normal composition without getting mocha in-between

mocha can bring A TON of edgecases

Yeah, that seems like a good solution. Loading oneFixture as a fixture when it's needed directly, but not nesting the loadFixture() calls. I'll change my tests to that. Thank you

i'd say you open an issue first so that we can discuss and and understand if it works

so that you don't impement it if it doesn't