Skip to content

[A23-10] [INFO] LibFlow sibling loops use inconsistent i++/++i increment #416

@thedavidmeister

Description

@thedavidmeister

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) {

Metadata

Metadata

Labels

auditAudit findinginfoSeverity: infopass4Audit Pass 4: Code Quality

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions