Remove unnecessary SafeMath calls
See original GitHub issueIts usage has become ubiquitous, but there are multiple instances where it is not needed. E.g. in ERC721
:
function _mint(address to, uint256 tokenId) internal {
..
_ownedTokensCount[to] = _ownedTokensCount[to].add(1);
..
}
That is the only place where _ownedTokensCount[to]
is incremented: 2^256 calls to _mint
are needed to make it overflow, making these calls more expensive by adding the check makes no sense.
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
OZ Contracts v4 + SafeMath - OpenZeppelin Forum
The origin of the discussion is that Solidity 0.8 includes checked arithmetic operations by default, and this renders `SafeMath` unnecessary.
Read more >SafeMath reduces gas cost? - blockchain - Stack Overflow
0, and I thought that it would reduces gas if we remove SafeMath. However, we tested both codes with and without SafeMath. The...
Read more >Solidity v0.8.0 Breaking Changes
The global functions log0 , log1 , log2 , log3 and log4 have been removed. These are low-level functions that were largely unused....
Read more >What is the purpose of "unchecked" in Solidity?
You do not need to include SafeMath in any of your contracts compiled using ... Each time i++ is called under/overflow checks are...
Read more >Exploring the new Solidity 0.8 Release - Solidity developer
0x51: Calling a zero-initialized variable of internal function type. ... Remove any Openzeppelin SafeMath, you won't need it anymore.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hm, we’ve usually been more of the “use safemath everywhere to be sure” camp. I think we should tackle this by using something like the
Counter
type that we have, although it doesn’t have adecrement
function that is needed for transfers and burning. Thoughts?We haven’t yet found a use case for
Counter
though, have we? If it had methods to both increment and decrement by one, we could remove therequire
frominc
, since it will never overflow. If there is indeed something that only ever increments, then we should create this new thing (IncDec
).