txframe blobify and persist#4220
Conversation
| pos += 2 | ||
| v | ||
|
|
||
| template readU32BE(data: openArray[byte]; pos: var int): uint32 = |
There was a problem hiding this comment.
It seems like every usage of readU16BE and readU32BE is immediately converted to an int. For readU16BE this is at least safe, but the various U32 fields read in necessarily compatible with signed 32-bit integers? It's true that the EL as a whole realistically probably can't target 32-bit platforms, but especially with some of the ZK efforts, it's proven, as it were, useful to retain 32-bit support for as much of the codebase as is feasible.
The calls for the U32 ones seem to be 100% for initTable, which seems like it could be either capped, or, maybe the values read in realistically won't be larger than a 32-bit signed int can store.
|
Is this diff cache pruned somewhere when base updates? |
Not yet, but will |
…int detour) blob.len widened to uint64 for the bounds comparisons aLen + 4 + 4 and kOff + 4 + kLen can't overflow uint64 int(...) only at the final blob.toOpenArray indexing — and by then the bounds check has guaranteed the value fits in int (since it's at most blob.len, itself an int)
2 participants
No description provided.