Rot127
Rot127
Is this `x86`? If yes it is likely that it won't be fixed in the near future with an update. Unfortunately the new [update mechanism](https://github.com/capstone-engine/capstone/issues/2015) doesn't work for `x86` (yet,...
Thank you for the PR! I closed it because it is out of date. With the new [auto-sync update for v6](https://github.com/capstone-engine/capstone/blob/next/docs/cs_v6_release_guide.md) we made many changes to some main architectures and...
Thank you for the PR! I closed it because it is out of date. With the new [auto-sync update for v6](https://github.com/capstone-engine/capstone/blob/next/docs/cs_v6_release_guide.md) we made many changes to some main architectures and...
> what do you think on this one. I personally think cstool should be independent of the type of the library it built with - static or dynamic, it should...
Wasn't the `make` way of building to be removed anyway? @kabeor You mentioned this several times I think.
Agree. There are some warnings disabled though in code with `pragma`. Need to remove those as well at some point.
Made a build with `-Wall` and `-Wpedantic`. We are not so far from passing `-Wall`! And `Wpedantic` seems mostly a problem with our header files. Added a list above.
@g0th1c54e4 Please add comments in English only. @No-47 Sorry, it just got to my attention again. Would you mind opening a PR for this? I won't have a Windows machine/VM...
Could you test the build on the current `next` branch. I remember someone added Mapping.c to the CMakeFiles I think.
Just as a note. LLVM saves immediate values in general as `int64_t`. We can think about doing just that. So we mimic LLVM as close as possible.