You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In ERC-223 tokenReceived's description reads: "It works by analogy with the fallback function of Ether transactions and returns nothing". But then: "The tokenReceived function must return 0x8943ec02 after handling an incoming token transfer. The tokenReceived function call can be handled by the fallback function of the recipient contact (and in this case it may not return the magic value 0x8943ec02)".
First, this is not clear what "may not return the magic value 0x8943ec02" means. It may mean that implementations of tokenReceived are allowed to return something other than 0x8943ec02 and this will be okay. And it may mean something completely opposite: that failback function can return something other than 0x8943ec02 and for this reason we mandate tokenReceived to return 0x8943ec02 to distinguish true tokenReceived from failback function.
I'm nearly sure that the second interpretation was intended. So, please, rephrase somehow this paragraph. Ideally, this sentence about failback function should be moved to rationale.
Also, we see phrase "It works by analogy with the fallback function of Ether transactions and returns nothing". Part "returns nothing" is wrong. It returns 0x8943ec02, not nothing.
Then: we see phrase "This function can be manually called by a EOA" here. What this means? That EOAs are allowed to call tokenReceived and tokenReceived should successfully handle this? Or opposite: tokenReceived implementations should beware that EOAs may call tokenReceived and thus should reject this? I suggest simply remove this phrase, because it adds nothing.
Also, I think I found some other problems in ERC-223, but I didn't write them down, so I don't remember them. If you want, I can re-read ERC-223 and possibly report additional problems
Relevant log output
No response
The text was updated successfully, but these errors were encountered:
Then: we see phrase "This function can be manually called by a EOA" here. What this means?
This is more of a security consideration to make it clear that if the tokenReceived function was invoked - it does not automatically mean that some token was deposited. A user could call it from a EOA.
Honestly this function can be called from a contract which is not a ERC-223 token, so it would be better to add that description as well.
We need to warn the implementers that the fact of tokenReceived function call does not automatically mean that tokens were deposited and they need to check that.
It works by analogy with the fallback function of Ether transactions and returns nothing
Yes, the "and returns nothing" is simply incorrect. In the old days of the standard implementation it indeed was returning nothing, but that was changed at some point and the description text was simply not updated. Needs a fix.
we mandate tokenReceived to return 0x8943ec02 to distinguish true tokenReceived from failback function.
This.
can be handled by the fallback function of the recipient contact (and in this case it may not return the magic value 0x8943ec02)
The word "may" was used because its possible to assemble a return value within fallback function by pushing something onto stack at the memory position where the returned value is expected to be stored, I'm pretty sure it was possible in solidity before 0.4.0 but that needs to be checked. The functon tokenReceived MUST return the magic value.
The implementer CAN check if the function call was handled by the tokenReceived or fallback by verifying if the returned value is magic value or not.
Pull Request
3344c58
What happened?
In ERC-223
tokenReceived
's description reads: "It works by analogy with the fallback function of Ether transactions and returns nothing". But then: "The tokenReceived function must return 0x8943ec02 after handling an incoming token transfer. The tokenReceived function call can be handled by the fallback function of the recipient contact (and in this case it may not return the magic value 0x8943ec02)".First, this is not clear what "may not return the magic value 0x8943ec02" means. It may mean that implementations of
tokenReceived
are allowed to return something other than 0x8943ec02 and this will be okay. And it may mean something completely opposite: that failback function can return something other than 0x8943ec02 and for this reason we mandatetokenReceived
to return0x8943ec02
to distinguish truetokenReceived
from failback function.I'm nearly sure that the second interpretation was intended. So, please, rephrase somehow this paragraph. Ideally, this sentence about failback function should be moved to rationale.
Also, we see phrase "It works by analogy with the fallback function of Ether transactions and returns nothing". Part "returns nothing" is wrong. It returns
0x8943ec02
, not nothing.Then: we see phrase "This function can be manually called by a EOA" here. What this means? That EOAs are allowed to call
tokenReceived
andtokenReceived
should successfully handle this? Or opposite:tokenReceived
implementations should beware that EOAs may calltokenReceived
and thus should reject this? I suggest simply remove this phrase, because it adds nothing.ping @Dexaran .
Also, I think I found some other problems in ERC-223, but I didn't write them down, so I don't remember them. If you want, I can re-read ERC-223 and possibly report additional problems
Relevant log output
No response
The text was updated successfully, but these errors were encountered: