Capstone disassembly/disassembler framework: Core (Arm, Arm64, BPF, EVM, M68K, M680X, MOS65xx, Mips, PPC, RISCV, Sparc, SystemZ, TMS320C64x, Web Assembly, X86, X86_64, XCore) + bindings. (bloaty 依赖)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

48 lines
1.4 KiB

1. API change
Version 2.1 changes the API cs_close() from (prototype):
cs_err cs_close(csh handle);
to:
cs_err cs_close(csh *handle);
Therefore, all C code written on top of Capstone must be fixed accordingly,
from something like:
csh handle;
//....
cs_close(handle); // <-- cs_close() used to take handle as argument.
to:
csh handle;
//....
cs_close(&handle); // <-- cs_close() now takes pointer to handle as argument.
Internally, this change is to invalidate @handle, making sure it cannot be
mistakenly used after the handle is closed.
NOTE: this change is on C interface only. All the bindings Python, Java or
bindings made by community such as C#, Go, Ruby & Vala should hide this change
behind their API. For this reason, code using these bindings still work exactly
like before and do not need to have any modification.
2. Upgrade bindings
Version 2.1 makes some changes to Java & Python bindings, like adding some new
instructions (affecting *_const.py & *_const.java). While this does not break
API compatibility (i.e users do not need to modify their program written with
prior version 2.0), they must upgrade these bindings and must not use the old
bindings from prior versions.
We cannot emphasize this enough: When upgrading to the new engine, always
upgrade to the bindings coming with the same core. If do not follow this
principle, applications can silently break without any clear evidence,
making it very hard to debug sometimes.