feat(rt): support round-trip transmute bytes <> u64 casts#804
feat(rt): support round-trip transmute bytes <> u64 casts#804automergerpr-permission-manager[bot] merged 8 commits intomasterfrom
Conversation
jberthold
left a comment
There was a problem hiding this comment.
Nice work! Just A few details to adjust...
We should probably add a simplification for the round-trip with symbolic values, like the one I added for amount in the p-token module.
kmir/src/tests/integration/data/prove-rs/show/byte-endian-fail.main.expected
Outdated
Show resolved
Hide resolved
Co-authored-by: Jost Berthold <jost.berthold@gmail.com>
Co-authored-by: Jost Berthold <jost.berthold@gmail.com>
| andBool lookupTy(TY_DEST_INNER) ==K lookupTy(TY_SRC_OUTER) // and is well-formed (invariant) | ||
| ``` | ||
|
|
||
| Casting a byte array/slice to an integer reinterprets the bytes in little-endian order. |
There was a problem hiding this comment.
I suspect this actually depends on architecture, and we do have access to that information in the configuration via the MachineInfo field Endian (link). Not sure if it is an easy inclusion but given we would then want to check it on different endian machines to ensure it works I think it's worth investigating right now. At least a note should be included as this should break on other architectures iiuc.
There was a problem hiding this comment.
Maybe we just add a TODO? We have a few more places where we assume little-endian byte order and machine word size 64bit.
|
I investigated this applied to p-token Details=> |
- close #697 --------- Co-authored-by: Jost Berthold <jost.berthold@gmail.com> Co-authored-by: Daniel Cumming <124537596+dkcumming@users.noreply.github.com>
Uh oh!
There was an error while loading. Please reload this page.