64 bit types and C libraries

[Regan Heath]

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:

struct bignum_st
	{
	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 */
	int flags;
	};

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.

Regan