Fixing DOS large exponent in scientific notation constants. #608
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes issue #579.
The issue was that slither was computing 10**HUGE_NUMBER eagerly in order to multiply it with the first part of the scientific notation.... which takes a while, and eats up lots of memory, because we're using bignums for this. I changed the behavior so that, if the first part is zero, just return zero. Otherwise, if the exponent is greater than 80, raise a ValueError, because there's no way the result will fit into a solidity integer type unless they're just writing it out in a really really troll-y way.
This will raise on something like
0.{80 zeros}1E80
. Not sure if solc supports that, but if we wanted to, we could add some sort of behavior with alternately multiplying the base by 10 and decrementing the exponent until it's zero... but that'd require some checks too to make sure the exponent isn't still too large.