|
| 1 | +# Memory Handling Differences: Hardhat vs Foundry |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +During the migration from Hardhat to Foundry testing framework, we encountered a fundamental difference in how these two EVM implementations handle memory operations. This document explains why the `test_WrapWithNonDefaultPointer` test from BytesMemory.t.sol had to be removed. |
| 6 | + |
| 7 | +## The Core Issue: Low-Level Memory Manipulation |
| 8 | + |
| 9 | +### What the Test Was Doing |
| 10 | + |
| 11 | +The `test_WrapWithNonDefaultPointer` test was designed to verify the functionality of a function that performs non-standard memory pointer manipulation: |
| 12 | + |
| 13 | +```solidity |
| 14 | +function wrapWithNonDefaultPointer(bytes memory data, uint256 n) |
| 15 | + returns (BytesMemory.Slice memory) |
| 16 | +``` |
| 17 | + |
| 18 | +This function attempts to: |
| 19 | +1. Take a bytes array from memory |
| 20 | +2. Add an arbitrary offset `n` to its pointer |
| 21 | +3. Create a new Slice struct with this modified pointer |
| 22 | +4. Return data from this custom memory location |
| 23 | + |
| 24 | +### Why It Works in Hardhat but Not in Foundry |
| 25 | + |
| 26 | +#### 1. **Different EVM Implementations** |
| 27 | + |
| 28 | +- **Hardhat**: Uses `ethereumjs-vm`, a JavaScript-based EVM implementation |
| 29 | +- **Foundry**: Uses `revm`, a Rust-based EVM implementation |
| 30 | + |
| 31 | +These implementations have different approaches to memory management and safety. |
| 32 | + |
| 33 | +#### 2. **Memory Layout Assumptions** |
| 34 | + |
| 35 | +**In Hardhat's EVM:** |
| 36 | +- Memory allocation follows predictable patterns |
| 37 | +- Pointer arithmetic is more permissive |
| 38 | +- Memory layout is consistent with the test's assumptions |
| 39 | + |
| 40 | +**In Foundry's revm:** |
| 41 | +- Memory allocation may use different strategies |
| 42 | +- Stricter memory safety checks |
| 43 | +- Different internal memory organization |
| 44 | + |
| 45 | +#### 3. **Safety vs Flexibility Trade-off** |
| 46 | + |
| 47 | +``` |
| 48 | +Hardhat (JavaScript EVM): |
| 49 | +┌─────────────────┐ |
| 50 | +│ More Permissive │ → Allows unsafe pointer arithmetic |
| 51 | +│ Less Strict │ → Matches original test assumptions |
| 52 | +│ Predictable │ → Consistent memory patterns |
| 53 | +└─────────────────┘ |
| 54 | +
|
| 55 | +Foundry (Rust revm): |
| 56 | +┌─────────────────┐ |
| 57 | +│ Safety First │ → Prevents unsafe operations |
| 58 | +│ Strict Checks │ → Blocks invalid pointer math |
| 59 | +│ Optimized │ → Different allocation strategy |
| 60 | +└─────────────────┘ |
| 61 | +``` |
| 62 | + |
| 63 | +## Technical Deep Dive |
| 64 | + |
| 65 | +### Memory Structure in Solidity |
| 66 | + |
| 67 | +In Solidity, a `bytes memory` variable consists of: |
| 68 | +``` |
| 69 | +[length (32 bytes)][data (n bytes)] |
| 70 | + ↑ |
| 71 | + pointer points here |
| 72 | +``` |
| 73 | + |
| 74 | +### What `wrapWithNonDefaultPointer` Does |
| 75 | + |
| 76 | +```solidity |
| 77 | +// Pseudo-code of what happens internally |
| 78 | +function wrapWithNonDefaultPointer(bytes memory data, uint256 n) { |
| 79 | + // 1. Get the pointer to 'data' |
| 80 | + uint256 ptr = getPointer(data); |
| 81 | +
|
| 82 | + // 2. Add arbitrary offset |
| 83 | + uint256 newPtr = ptr + n; // ⚠️ UNSAFE! |
| 84 | +
|
| 85 | + // 3. Create slice with modified pointer |
| 86 | + return Slice(newPtr, data.length); |
| 87 | +} |
| 88 | +``` |
| 89 | + |
| 90 | +### Why This Is Problematic |
| 91 | + |
| 92 | +1. **Undefined Behavior**: Adding arbitrary offsets to pointers can point to: |
| 93 | + - Uninitialized memory |
| 94 | + - Memory belonging to other variables |
| 95 | + - Outside allocated memory bounds |
| 96 | + |
| 97 | +2. **Implementation-Specific**: The test relies on: |
| 98 | + - Specific memory allocation patterns |
| 99 | + - Predictable memory layout |
| 100 | + - Lack of safety checks |
| 101 | + |
| 102 | +3. **Not EVM-Specified**: The EVM specification doesn't guarantee: |
| 103 | + - How memory is allocated |
| 104 | + - That pointer arithmetic will work consistently |
| 105 | + - Memory layout between different implementations |
| 106 | + |
| 107 | +## Memory Allocation Differences |
| 108 | + |
| 109 | +### Hardhat's Approach |
| 110 | +``` |
| 111 | +Memory: [FREE][VAR1][FREE][VAR2][FREE] |
| 112 | + ↑ Predictable gaps |
| 113 | + ↑ Consistent layout |
| 114 | + ↑ Pointer math "works" |
| 115 | +``` |
| 116 | + |
| 117 | +### Foundry's Approach |
| 118 | +``` |
| 119 | +Memory: [VAR1][VAR2][GUARD][VAR3][GUARD] |
| 120 | + ↑ Optimized packing |
| 121 | + ↑ Safety guards |
| 122 | + ↑ Pointer math blocked |
| 123 | +``` |
| 124 | + |
| 125 | +## Implications |
| 126 | + |
| 127 | +### For Testing |
| 128 | +- Tests relying on implementation details will fail |
| 129 | +- Focus on testing contract behavior, not EVM internals |
| 130 | +- Avoid tests that depend on memory layout |
| 131 | + |
| 132 | +### For Production Code |
| 133 | +- **Never** use such low-level memory tricks in production |
| 134 | +- These patterns are inherently unsafe |
| 135 | +- Different nodes may handle them differently |
| 136 | + |
| 137 | +### Best Practices |
| 138 | +1. Use standard Solidity memory operations |
| 139 | +2. Don't manipulate pointers directly |
| 140 | +3. Test behavior, not implementation |
| 141 | +4. Avoid relying on EVM implementation details |
| 142 | + |
| 143 | +## Conclusion |
| 144 | + |
| 145 | +The removal of `test_WrapWithNonDefaultPointer` is not a limitation but rather a safety feature. Foundry's stricter memory handling prevents tests (and potentially production code) from relying on unsafe, implementation-specific behavior. |
| 146 | + |
| 147 | +While Hardhat's permissive approach allowed such tests to pass, Foundry's safety-first philosophy ensures that only well-defined, safe operations are permitted. This aligns with best practices for writing robust, portable smart contracts that will work consistently across different EVM implementations. |
| 148 | + |
| 149 | +## Alternative Approaches |
| 150 | + |
| 151 | +If you need to test memory slicing functionality: |
| 152 | +1. Use standard offset/length parameters |
| 153 | +2. Work within Solidity's memory safety model |
| 154 | +3. Test the public API, not internal memory manipulation |
| 155 | +4. Consider if the functionality is truly needed |
| 156 | + |
| 157 | +Remember: If it requires unsafe memory tricks, it's probably not a good pattern for production smart contracts. |
0 commit comments