Closed zwimer closed 1 year ago
I have a PR in the works, but more Z3 info gathering is required via: https://github.com/Z3Prover/z3/discussions/6443
Proposed solution @ltfish :
StringS
length is always fixed to max_length
in claripy; unbounded in Z3StringS
length is encoded in Z3 names, but unbounded in Z3- for StringS
who do not have it encoded in their name when abstracting to claripy, we set it to max_length
StringS
in z3@ltfish I think we should just do 3 since other things read Z3 names like our unsat core stuff and fixing the length after abstraction feels like a correctness issue. So I think just disallowing z3 support is fine, since we already don't support it via the fact that the code will error.
I disallowed StringS
abstraction in the z3 backend in the linked PR since it doesn't work anyway. I added a warning for StringS
conversion. Functionally this just cleans up exceptions and adds an logging warning.
Description
Claripy cannot properly abstract string symbols from Z3
Steps to reproduce the bug
Yields
Environment
Master: https://github.com/angr/claripy/commit/728cc9d1bedc7c19aa1a6a318262e83e69be0a00
Additional context
No response