Add test to assert identical layout of context structs

[thomaseizinger]

For this crate to work properly, we are relying on the layout of the context struct of libsecp256k1 and libscep256k1-zkp to be identical.

We should add a sanity test that verifies this so we can detect mismatches early.

[jonasnick]

Do you have an idea for how to best do that?

[thomaseizinger]

I am no longer sure if it is so pressing.

All the tests in this library are now using the libsecp256k1 context with the functions defined in libsecp256k1-zkp. If the contexts are not compatible, these tests will segfault. I noticed that because when I first converted this lib to depend on rust-secp256k1, I did not enable the endomophrism feature and hence the contexts were not compatible.

They can of course segfault for other reasons as well. Having a test that compares the layout would be a nice indicator to know what the problem could be if the tests break after an update of the vendored code. Other than that, I don't think it would be very useful.

I found this: https://github.com/Jongy/struct_layout

However, it seems a bit cumbersome to include that in an automated fashion. I guess a standalone tool that takes two commit hashes (one from libsecp256k1 and one from libsecp256k1-zkp), clones the repos, compiles them with this plugin and compares the layouts would suffice as well.

But as I said, I am not sure if it is worth the effort. I don't see any danger in us shipping something that is broken because we test everything in this crate using the libsecp256k1 context.

[jonasnick]

Okay, I thought perhaps you had come up with a simple, elegant solution that I missed.

If the contexts are not compatible, these tests will segfault.

I don't think that's true. Basically anything can happen including behavior that is not (currently) covered by tests. For now I agree it's okay to keep this issue in mind when updating the dependencies (and when considering context changes in c-secp and c-secp-zkp) and hope that the unit tests would catch issues.

Worth noting that there's a possibility for context incompatibilities when vendoring secp-zkp, but also when updating the rust-secp256k1 dependency. So any tool would have to be run in both cases.