Closed mds1 closed 8 months ago
I find this auditor as a very useful tool.
The problem with structs in function selector is not the only issue: it don't parse by any mean the interfaces. May be I have to open a new issue regarding this problem?
E.g.: if we use Remix in a contract with the method:
function rateByPath(IERC20[] calldata _path, uint256 _amount)
It is parsed as: "convertByPath(address[],uint256,uint256,address,address,uint256)", with the selector:
"b77d239b": "convertByPath(address[],uint256,uint256,address,address,uint256)"
,
But the vscode-solidity-auditor do the wrong calculation:
ded49702: "convertByPath(IERC20[],uint256,uint256,address,address,uint256)"
As another note, for fixed sized arrays the wrong function sig is shown too:
For "function arr(uint[2] memory param)" it returns "bfceb977 => arr(uint256[])"
Correct output would be "d1578977 => arr(uint256[2])"
I guess I really have to refactor the funcsig extraction part. If anyone want's to take this on, I'm open for PRs :)
"funcSig" over a function and "funcSigs" at the top of the file report 2 different signature values for the same function. The problem arises if a function has in parameter of struct array. The "funcSig" even reports the struct array parameter as address array while the "funcSigs" reports it as struct array. Signature reporting feature is a useful feature, and I would like it to be fixed.
Hey again @tintinweb—I know in #68 you mentioned the signature extraction is hacky and you don't expect many people use it, but actually it's probably the feature I use most, so here's another related issue 😁
The issue:
0x9120491c
0xe1acd927
In this case the method linked is an array of structs. I think I've also seen regular structs and interfaces (e.g.
function someMethod(IERC20 _address)
) give the wrong function signature, though I don't have an example handy—I can double-check and confirm this if you need