You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just found out that starting from version 5.0.1, the value of CS_OP_MEM (accessed from the python library) has changed, from 3 to 128, potentially causing issues in automated tools that make use of such constant value to check the type of the operands of an instruction.
Below a python run that shows the difference, using as example the x86 instruction mov eax, dword ptr [rsp + 0x14]:
Thanks for pointing this out. Turns out this was accidentally pulled in, because we wanted to have the TriCore architecture being part of v5. TriCore used the new auto-sync updater (will be released with v6) for creation. And architectures using it require to distinguish registers/immediate values used for memory and non memory registers/immediate values.
TriCore though probably doesn't require the value change? @imbillow
I propose to change it back for v5.0.2? It's annoying to have this inconsistency between those versions. But IMHO it is still better, because people can get a clear pre-AutoSync version and a post-AutoSync version of Capstone.
cc @kabeor@XVilka (candidate for #2081)
Hi,
I just found out that starting from version 5.0.1, the value of CS_OP_MEM (accessed from the python library) has changed, from 3 to 128, potentially causing issues in automated tools that make use of such constant value to check the type of the operands of an instruction.
Below a python run that shows the difference, using as example the x86 instruction
mov eax, dword ptr [rsp + 0x14]
:Capstone version 5.0.0
Capstone version 5.0.1
So my question is: is this an issue or is there another constant available to check the operand type?
Thanks in advance for the support.
The text was updated successfully, but these errors were encountered: