Interestingly, if I modify the code to return xarr.length instead of zarr.length (i.e. the length of the first dynamic array parameter instead of the second dynamic array parameter), the spec actually passes successfully (once the output cell is updated to output: _ => #encodeArgs(#uint256(X_LEN)). This seems to suggest that something may be missing from the spec or rewrite rules to handle extracting the length of a dynamic array parameter which is preceded by another dynamically-size array.
I looked at the edsl.k file, and I couldn't figure out how the following rewrite rule would work:
rule #enc(#array(_, N, DATA)) => #enc(#uint256(N)) ++ #encodeArgs(DATA)
especially when compared to the similar rule for #enc(#bytes(WS)) which seems to "bottom-out" rather than recursively encoding WS via #encodeArgs:
Hi, I'm having difficulty verifying this program using the following eDSL:
Interestingly, if I modify the code to return
xarr.length
instead ofzarr.length
(i.e. the length of the first dynamic array parameter instead of the second dynamic array parameter), the spec actually passes successfully (once the output cell is updated tooutput: _ => #encodeArgs(#uint256(X_LEN))
. This seems to suggest that something may be missing from the spec or rewrite rules to handle extracting the length of a dynamic array parameter which is preceded by another dynamically-size array. I looked at theedsl.k
file, and I couldn't figure out how the following rewrite rule would work:especially when compared to the similar rule for
#enc(#bytes(WS))
which seems to "bottom-out" rather than recursively encoding WS via#encodeArgs
:Is there something missing from my spec?