Add trailing zeros padding to _toString #415
Merged
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.
When assembly is used to directly return the string (i.e. using
return(offset, length)
in Yul), it skips the built-in Solidity bookkeeping to copy and pad the string with zeros to the next word.This can cause some issues with Etherscan decoding, like the
name()
function on Seaport.Credits to @hrkrshnn for highlighting this obscure behavior.
This PR allocates an extra zeroed word to pad the string at the end, at the cost of a little additional gas. This is in case someone tries to use Yul to return strings.
Currently, using the unpadded
_toString
in plain Solidity, or inabi.encodePacked
, or instring.concat
will not cause any frontend issue. As long as devs don't use assembly to directly return the result of the unpadded_toString
, the frontends will decode fine (probably near 100% of devs -- even I don't do manual assembly returns for strings).