64 bit types and C libraries
regan at netmail.co.nz
Tue May 22 08:22:00 PDT 2007
Daniel Keep Wrote:
> torhu wrote:
> > How's the BIGNUM struct defined?
> As far as I can tell, the OpenSSL docs don't specify; they state that
> BIGNUM should be treated as an opaque type, and that you must never
> attempt to directly access its members.
> That practically screams of "BIGNUM's implementation is
> platform-dependant" :P
Yep, it looks like this:
BN_ULONG *d; /* Pointer to an array of 'BN_BITS2' bit chunks. */
int top; /* Index of last used d +1. */
/* The next are internal book keeping for bn_expand. */
int dmax; /* Size of the d array. */
int neg; /* one if the number is negative */
which answers the question "is it 64 bits", the answer is "nope".
> Actually, PQ_64BIT can be aliased to BIGNUM which can be an *arbitrary*
> number of bits; it's a dynamically allocated structure.
Yep, that's the problem as I see it.
> However, if his version is compiled with 64-bit integer support, and he
> doesn't mind not supporting BIGNUM versions, he could just stick to
> ulong. Maybe just stub out the other side of the version path with some
> static assert(false)'s. :)
This is what I did, to progress with other parts in the meantime.
However, I think I may need to re-think my strategy.
I started with ssl.h, the top level C include file. Created an ssl.d copying/converting everything, then compiled with a main.d which imported openssl.ssl;
This kicked up all the undefined symbols (handled by includes in the original source) I tracked the first of these and converted that file, however, each new source includes more undefined symbols and I end up in the murky depths of openssl.
The problem with my method is that of course I am going to end up converting the whole thing one file at a time.
It just strikes me that I should be able to get away with converting less, just the stuff a library end-user would actually use. Maybe I should start by identifying that.. hmm.
More information about the Digitalmars-d-learn