Apologies for the delayed joining of the discussion. I chose to use BN to implement 64-bit numbers because (1) it was little code, (2) the abstraction was clean, (3) BN works on all supported platforms, (4) the places where emulated 64-bit numbers are used are not performance critical, and (5) no changes were required outside of pqueue and DTLS code.
> appro> 1. I'm reluctant to include bn.h to non-bn code, because it's > appro> nothing but counterintuitive [and is not good in long run]. > appro> 2. My standpoint is [still] that pqueue/dtls1 should not have > appro> dependancy on bh.h either. I don't quite follow this point. Is it that pqueue is not self-contained? (There are already a number of cross-dependancies in libcrypto, including on bn.h) > appro> 3. Using BIGNUM for DTLS purposes is *total* overkill. To back > appro> this up I'm going to suggest alternative, 64-bit neutral pq > appro> code shortly:-) That works for me. Though, I'll add that neither pqueue nor DTLS do anything heavy with PQ_64BIT--the performance gain for the few platforms that do need the specialized code will be minimal. nagendra ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
