Support Swift Package Manager

[Mx-Iris]

Detailed description

This pull request adds Swift Package Manager support to capstone, allowing capstone to be imported as a dependency in Swift.

[Rot127]

Thanks for this contribution! I hope I find some time later this week to read into Swift. I never used it.

What would be your way to test these bindings?

[Mx-Iris]

Thanks for this contribution! I hope I find some time later this week to read into Swift. I never used it.

What would be your way to test these bindings?

I will write some test cases later or use existing test code to build a test module. Once completed, you just need to run the swift test command.

[Mx-Iris]

Thanks for this contribution! I hope I find some time later this week to read into Swift. I never used it.

What would be your way to test these bindings?

Since only the C interface is exposed here (Swift can directly call C), only the C code needs to be tested. For a more complete Swift binding, I would prefer to write another swift-capstone package (in fact, there is one already, but it only adapts to v5).

[Rot127]

I will write some test cases later or use existing test code to build a test module. Once completed, you just need to run the swift test command.

Nice! Thanks a lot!

Just having some testing is really required. So we have a chance to catch errors in case there are ABI issues.

[Mx-Iris]

I will write some test cases later or use existing test code to build a test module. Once completed, you just need to run the swift test command.

Nice! Thanks a lot!

Just having some testing is really required. So we have a chance to catch errors in case there are ABI issues.

I've written some simple Swift test code, and you can now run swift test in the project root directory to check it.

[santalvarez]

(in fact, there is one already, but it only adapts to v5).

Hi! I have recently updated capstone-swift to work with 5.0.6 as the current implementation was designed for v4 and missed some definitions added in v5.

I will be adding support for v6 soon. @Mx-Iris

[wtdcode]

I suggest that a new CI workflow be added as well, as this might break during our future development.

It also helps us to understand how to test it.

[Rot127]

Hope I find time to review it next week. @santalvarez If you want to, feel free to leave your review here as well.

[Mx-Iris]

Thanks for your contribution. I never wrote Swift so be so kind and be explicit in your explanations when you answer the comments.

Regarding the tests:

They only print something to the screen. They don't test actual values. In case you want to continue like this we can only merge it into a separated branch. But not into the next branch. The test cases are not sufficient enough for this.

If you want to have it in the next branch it is required that you implement the equivalent of cstest_py. So it needs to run all test cases in tests/ and compare the values.

That said, the test code looks AI generated to me. Apologies if I am mistaken. But if not not, please don't contribute fully generate code.

Thank you for your patient review. This PR does not add any new code. If we need to write corresponding Swift tests for every use case, the workload would be very large. I will try to see if I can reuse the cstest_py code. I think it should be fine as long as swift build succeeds.

[Rot127]

I will try to see if I can reuse the cstest_py code. I think it should be fine as long as swift build succeeds.

I am not familiar with Swift at all (and have limited time to read into it currently). So I can't judge what possibilities of bugs are on the ABI level. Is it just calling the C functions? Are the primitive types guaranteed to have the same bit width? All these things let to bugs with the Python bindings. This is why it is so important to me to have it tested.

cstest_py doesn't do much. It just parses the Yaml files in tests/ and disassembles the input data with its Python disasm() function. Then compares the output. If the output mismatches it fails.

I know adding it is not a quick task, and can take two to three days, but with v6 we raised the bar of testing quite significantly. And I really would like to keep it. I consider Capstone infrastructure because it provides a basic function and is used in many big projects. This is why I personally push for more test coverage where ever possible.

If the others like @kabeor @wargio @wtdcode or @jiegec over vote me it is fine. But I would sleep better if our test coverage grows with each addition.

[Mx-Iris]

I will try to see if I can reuse the cstest_py code. I think it should be fine as long as swift build succeeds.

I am not familiar with Swift at all (and have limited time to read into it currently). So I can't judge what possibilities of bugs are on the ABI level. Is it just calling the C functions? Are the primitive types guaranteed to have the same bit width? All these things let to bugs with the Python bindings. This is why it is so important to me to have it tested.

cstest_py doesn't do much. It just parses the Yaml files in tests/ and disassembles the input data with its Python disasm() function. Then compares the output. If the output mismatches it fails.

I know adding it is not a quick task, and can take two to three days, but with v6 we raised the bar of testing quite significantly. And I really would like to keep it. I consider Capstone infrastructure because it provides a basic function and is used in many big projects. This is why I personally push for more test coverage where ever possible.

If the others like @kabeor @wargio @wtdcode or @jiegec over vote me it is fine. But I would sleep better if our test coverage grows with each addition.

Okay, I understand. I will submit a new PR as soon as possible.

[Rot127]

@santalvarez Do you see cooporation potential btw? Since you folks work on the same problem.

[wargio]

@Rot127 if this pr just adds a bunch of links, why not just keep the script and generate them for the release zip/tarball and keep the sources clean?

[Rot127]

if this pr just adds a bunch of links, why not just keep the script and generate them for the release zip/tarball and keep the sources clean?

Good point. In this case it would be just an implementation of cstest_swift and a script setting the links.

[santalvarez]

@santalvarez Do you see cooporation potential btw? Since you folks work on the same problem.

Yeah of course I'd love to cooperate on this.

@Mx-Iris I was reviewing this PR and I had a question. What advantage does this provide over the capstone-swift bindings specially considering that by adding capstone-swift to your swift project you can already do import Ccapstone and access everything the C capstone library exposes.

[Mx-Iris]

@Mx-Iris I was reviewing this PR and I had a question. What advantage does this provide over the capstone-swift bindings specially considering that by adding capstone-swift to your swift project you can already do import Ccapstone and access everything the C capstone library exposes.

capstone-swift imports Ccapstone using brew. This PR allows to import it from source, without any other dependencies.