Vyper's `extract32` can ready dirty memory
### Summary
When using the built-in `extract32(b, start)`, if the `start` index provided has for side effect to update `b`, the byte array to extract `32` bytes from, it could be that some dirty memory is read and returned by `extract32`.
As of v0.4.0 (specifically, commit
https://github.com/vyperlang/vyper/commit/3d9c537142fb99b2672f21e2057f5f202cde194f) the compiler will panic instead of generating bytecode.
### Details
Before evaluating `start`, the function `Extract32.build_IR` caches only:
- The pointer in memory/storage to `b`:
https://github.com/vyperlang/vyper/blob/10564dcc37756f3d3684b7a91fd8f4325a38c4d8/vyper/builtins/functions.py#L916-L918
- The length of `b`:
https://github.com/vyperlang/vyper/blob/10564dcc37756f3d3684b7a91fd8f4325a38c4d8/vyper/builtins/functions.py#L920-L922
but do not cache the actual content of `b`. This means that if the evaluation of `start` changes `b`'s content and length, an outdated length will be used with the new content when extracting 32 bytes from `b`.
### PoC
Calling the function `foo` of the following contract returns `b'uuuuuuuuuuuuuuuuuuuuuuuuuuu\x00\x00789'` meaning that `extract32` accessed some dirty memory.
```Vyper
var:Bytes[96]
@internal
def bar() -> uint256:
self.var = b'uuuuuuuuuuuuuuuuuuuuuuuuuuuuuu'
self.var = b''
return 3
@external
def foo() -> bytes32:
self.var = b'abcdefghijklmnopqrstuvwxyz123456789'
return extract32(self.var, self.bar(), output_type=bytes32)
# returns b'uuuuuuuuuuuuuuuuuuuuuuuuuuu\x00\x00789'
```
### Impact
For contracts that are affected, it means that calling `extract32` returns dirty memory bytes instead of some expected output.