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 in abi.encodePacked, or in string.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).
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
_toStringin plain Solidity, or inabi.encodePacked, or instring.concatwill 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).