The general overflow judgment condition for function sub is not in every case.
The judgment result is wrong in the condition of b < 0 && q >=0
for example, b = -3, q = 2, diff = -5, it's not overflow,
but if (diff > b) == (b >= 0 && q >= 0) wil be true.
for another example, b = -3, q = maxint, b-q is overflow,
but if (diff > b) == (b >= 0 && q >= 0) wil be false.
Signed-off-by: yjwxfq <112159687+yjwxfq@users.noreply.github.com>
* fixed comment consistency problem with erc20 chaincode
Signed-off-by: Ali Shahverdi <ali@Alis-MacBook-Pro.local>
* added more comment consistancy fix
Signed-off-by: Ali Shahverdi <ali@Alis-MacBook-Pro.local>
* added more comment consistancy fix
Signed-off-by: Ali Shahverdi <ali@Alis-MacBook-Pro.local>
* added more comment consistancy fix
Signed-off-by: Ali Shahverdi <ali@Alis-MacBook-Pro.local>
* added more comment consistancy fix
Signed-off-by: Ali Shahverdi <ali@Alis-MacBook-Pro.local>
Signed-off-by: Ali Shahverdi <ali@Alis-MacBook-Pro.local>
Co-authored-by: Ali Shahverdi <ali@Alis-MacBook-Pro.local>
Using the ERC-20 sample, you can submit a transfer to and from
the same account. Because the code doesn't handle this, it ends
up minting new tokens into that account.
The correct behaviour is not specified by the ERC-20 specification,
although the OpenZeppelin implementation seems to permit it.
IMO we should just block it with an error because I can't see a use
case for allowing it and it is most likely a user error.
Signed-off-by: Simon Stone <sstone1@uk.ibm.com>
