Preimage-shape tests assert a 96-byte length that cannot fail
File: test/src/lib/LibICloneableFactoryV4.t.sol lines 75-80,104-108 (solidity)
Dimension: pass5 · Severity: INFO
testEffectiveSaltPreimageShape and testEffectiveOpenSaltPreimageShape each build a local preimage with abi.encodePacked over three bytes32-typed values and then assertEq(preimage.length, 96) (lines 78 and 106). abi.encodePacked of three static 32-byte values is 96 bytes by the language, for every input, so neither assertion can fail and neither says anything about the library. The NatSpec presents the length as the pinned property ("The namespaced preimage is 96 bytes whose FIRST word is…"), but the library's preimage shape is actually pinned by the following assertEq(effectiveSalt(...), keccak256(preimage)) — that is what would break if abi.encode in the library stopped producing 96 bytes. The vacuous line reads as coverage of the 96-byte spec clause and is not.
Proposed fix
test/src/lib/LibICloneableFactoryV4.t.sol:78 and :106 — delete both assertEq(preimage.length, 96); lines; the keccak equality on the next line is the whole pin.
Verifier's reason
At ffd3041, test/src/lib/LibICloneableFactoryV4.t.sol:76-79 and :105-107 build preimage from three bytes32-typed values via abi.encodePacked, so assertEq(preimage.length, 96) (lines 78, 106) is statically true for every input and says nothing about the library; the pin is the next line's assertEq(effectiveSalt/effectiveOpenSalt(...), keccak256(preimage)), which would fail if src/lib/LibICloneableFactoryV4.sol:79/:92 stopped producing the 96-byte abi.encode preimage (contrast the non-vacuous assertEq(creationCode.length, 55) at LibICloneableFactoryV4.cloneCreationCode.t.sol:22, where the length comes back from the library). No owner ruling or non-finding clause covers it, and deleting the two lines removes only redundancy.
Found by the whole-repo audit (skill 0.35.0) at ffd3041. Declared scope: whole-repo.
Preimage-shape tests assert a 96-byte length that cannot fail
File:
test/src/lib/LibICloneableFactoryV4.t.sollines75-80,104-108(solidity)Dimension: pass5 · Severity: INFO
testEffectiveSaltPreimageShapeandtestEffectiveOpenSaltPreimageShapeeach build a localpreimagewithabi.encodePackedover threebytes32-typed values and thenassertEq(preimage.length, 96)(lines 78 and 106).abi.encodePackedof three static 32-byte values is 96 bytes by the language, for every input, so neither assertion can fail and neither says anything about the library. The NatSpec presents the length as the pinned property ("The namespaced preimage is 96 bytes whose FIRST word is…"), but the library's preimage shape is actually pinned by the followingassertEq(effectiveSalt(...), keccak256(preimage))— that is what would break ifabi.encodein the library stopped producing 96 bytes. The vacuous line reads as coverage of the 96-byte spec clause and is not.Proposed fix
test/src/lib/LibICloneableFactoryV4.t.sol:78 and :106 — delete both
assertEq(preimage.length, 96);lines; the keccak equality on the next line is the whole pin.Verifier's reason
At ffd3041, test/src/lib/LibICloneableFactoryV4.t.sol:76-79 and :105-107 build
preimagefrom three bytes32-typed values via abi.encodePacked, soassertEq(preimage.length, 96)(lines 78, 106) is statically true for every input and says nothing about the library; the pin is the next line'sassertEq(effectiveSalt/effectiveOpenSalt(...), keccak256(preimage)), which would fail if src/lib/LibICloneableFactoryV4.sol:79/:92 stopped producing the 96-byte abi.encode preimage (contrast the non-vacuousassertEq(creationCode.length, 55)at LibICloneableFactoryV4.cloneCreationCode.t.sol:22, where the length comes back from the library). No owner ruling or non-finding clause covers it, and deleting the two lines removes only redundancy.Found by the whole-repo audit (skill 0.35.0) at ffd3041. Declared scope:
whole-repo.