Description
LibFlow has three sibling transfer functions (flowERC20, flowERC721, flowERC1155) that share an identical for loop shape, but use inconsistent increment style:
LibFlow.sol:79 (flowERC20): for (uint256 i = 0; i < flowTransfer.erc20.length; i++)
LibFlow.sol:103 (flowERC721): for (uint256 i = 0; i < flowTransfer.erc721.length; ++i)
LibFlow.sol:122 (flowERC1155): for (uint256 i = 0; i < flowTransfer.erc1155.length; i++)
Two functions use post-increment (i++), one uses pre-increment (++i). All three loops are inside unchecked blocks where the codegen difference is irrelevant, so this is purely a style inconsistency between sibling functions that should look identical.
This is in the same family as A23-1 (#304, harmonise from-allowed check across flowERC20/721/1155) — sibling functions drifting in shape without semantic reason.
Location
src/lib/LibFlow.sol:79, src/lib/LibFlow.sol:103, src/lib/LibFlow.sol:122
Proposed fix
Standardise on one form across all three loops. ++i is the more common Solidity convention for unchecked loop counters; either works:
- for (uint256 i = 0; i < flowTransfer.erc20.length; i++) {
+ for (uint256 i = 0; i < flowTransfer.erc20.length; ++i) {
...
- for (uint256 i = 0; i < flowTransfer.erc1155.length; i++) {
+ for (uint256 i = 0; i < flowTransfer.erc1155.length; ++i) {
Description
LibFlowhas three sibling transfer functions (flowERC20,flowERC721,flowERC1155) that share an identicalforloop shape, but use inconsistent increment style:LibFlow.sol:79(flowERC20):for (uint256 i = 0; i < flowTransfer.erc20.length; i++)LibFlow.sol:103(flowERC721):for (uint256 i = 0; i < flowTransfer.erc721.length; ++i)LibFlow.sol:122(flowERC1155):for (uint256 i = 0; i < flowTransfer.erc1155.length; i++)Two functions use post-increment (
i++), one uses pre-increment (++i). All three loops are insideuncheckedblocks where the codegen difference is irrelevant, so this is purely a style inconsistency between sibling functions that should look identical.This is in the same family as A23-1 (#304, harmonise from-allowed check across
flowERC20/721/1155) — sibling functions drifting in shape without semantic reason.Location
src/lib/LibFlow.sol:79,src/lib/LibFlow.sol:103,src/lib/LibFlow.sol:122Proposed fix
Standardise on one form across all three loops.
++iis the more common Solidity convention for unchecked loop counters; either works: