-
Notifications
You must be signed in to change notification settings - Fork 12.4k
Fix ERC165Checker detection #5880
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
Merged
Merged
Changes from 9 commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
a827be1
Fix ERC165
ernestognw ed19036
minor mock/test refactor
Amxx 49ef98f
use assembly call
Amxx b3a2c82
cleanup loaded value
Amxx e3c2544
up
ernestognw 75ae31b
Add changeset
ernestognw 0b37c2f
Merge branch 'master' into inaccuracies
ernestognw 6093319
Remove changeset and add to changelog
ernestognw 1950904
Update CHANGELOG.md
ernestognw 7416347
Update contracts/utils/introspection/ERC165Checker.sol
Amxx File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why are we checking x!=0 as opposed to x==1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want anything that's not 0 to be interpreted as true. I think the rationale was to avoid the
abi.decodeto revert (see here). With assembly that might not be relevant anymore.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a contract returns 2, is that considered true according to the ERC? I'd argue no.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's technically correct because the ERC only distinguishes between 0 and 1 (false and true), so it's unclear how to treat the entire 32-byte value returned. I agree it's not ideal.
I would keep it for backwards compatibilty
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think its a big deal but anything other than 1 is definitely not true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'll break one of our tests, though
#5880 (comment)
I think we should weigh @Amxx opinion here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah sourcery beat me here. @Amxx seems to want to keep it as is.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we should consider all non-zero value as true, or if only 1 should be considered true. I guess both approach make sens.
What I'm sure is that so far (since OZ 2.0.0), the library assumed all non zero mean true. Changing that behavior is a breaking change. I would avoid that unless we have very strong reasons to change the behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also agree it is not a big deal, though should we take the opportunity to update it in 6.0?