Section 5: T-swap, Lesson 13- Stateful Fuzzing

[SquilliamX]

Hi everyone, I just finished lesson 13 of section 5 and we created a stateful fuzz test to find bugs within the StatefulFuzzCatches.sol contract. Before we set the fail_on_revert to equal false, it was reverting on a failed test for an arithmetic underflow or overflow. We then turn fail_on_revert to equal false in the foundry.toml, but isn't this arithmetic underflow or overflow also another bug? We just ignored it in the lesson because we were focused on making sure that the StatefulFuzzCatches.sol would not equal 0 and that is the invariant that we are testing, but if this was a competitive audit, wouldn't this arithmetic underflow or overflow be another bug finding that we could submit?

Thanks for your time!

[EngrPips]

Actually arithmetic underflow and overflow are bugs but not in the context where we are fuzzing and the fuzzer is throwing value that are not reasonable to the contract, in some cases where we have some sort of deposit function on a contract and the fuzzer deposited 700 billion ETH , does that even make sense. I mean, who has 700 billion ETH in the real world is the total supply of ETH even up to that. so you just have to be realistic when you want to assert that their is a bug and make sure everything simulates reality at least.

[PatrickAlphaC]

Sometimes, all we care about is if a transaction reverts or not. If a transaction would have broken a protocol invariant, but it reverted due to some overflow check -> well that's great! We want it to fail! But having fail_on_revert to true would mean our test would fail -> even though the revert happening is the correct functionality to keep the protocol invariant in check.

Hopefully that makes sense.

[EngrPips]

Makes sense