Although wrapping was relatively easy it basically meant
that we depend on C compilation which becomes nightmare
as soon as multiple platforms are used. I’ve got a huge pain
once iOS was involved with 3 device archs and 2 simulator
arches to support, not mentioning different set of include
and lib flags.
So there are 2 different approaches:
- continue this way, maintaining all compilation issues like
like managing correct flags, providing correct paths and so
on. This way our Makefile will grow extremely fast and will
actually take more efforts to maintain.
- doing it pure Rust way. In this case we provide all the
macros expansions inside our wrappers and there should be
no other way to access raw data other than through those
wrappers. It might be fragile if OpenSSL internal data
structures will ever change, but I think (or hope) it is
pretty stable and wouldn’t change anytime soon.
This PR eliminates `BN_is_zero` at all from public API. It’s
functionality is implemented in `BigNum.is_zero` and should
be enough.
Additional notes:
1. I’ve moved BIGNUM into `bn` so it could access fields
directly and keep it as an opaque structure for everyone
else
2. I’ve kept empty Makefile as I hope to land `feature-matrix`
branch soon and I don’t like merging deleted/added file
conflicts.
This is necessary because on some architectures BN_is_zero
is a CPP macro, so trying to link against it in an `extern "C"`
block causes a linker error.
This also introduces a build command to Cargo to compile
the bn_is_zero wrapper.
Richard Diamond