appro> > appro> 1. I'm reluctant to include bn.h to non-bn code, because it's
appro> > appro> nothing but counterintuitive [and is not good in long run].
appro> > appro> 2. My standpoint is [still] that pqueue/dtls1 should not have
appro> > appro> dependancy on bh.h either.
appro> > appro> 3. Using BIGNUM for DTLS purposes is *total* overkill. To back
appro> > appro> this up I'm going to suggest alternative, 64-bit neutral pq
appro> > appro> code shortly:-)
appro> >
appro> > I agree.
appro>
appro> Consider http://cvs.openssl.org/chngview?cn=13985 for 0.9.8.
That was... unexpected :-). I was expecting some better kind of
64-bit emulating type, but definitely not an array of unsigned char.
We sometimes forget that short array of unsigned chars can be useful
too:-) But what is concern? Performance? Of course subtracting of two
values in registers is way faster than satsub64be, *but* keep in mind
that those values get collected into registers with character loads and
shifts first, so altogether it's hardly faster [just a tad]. The only
concern is probably traversing pqueue... But the list is not expected to
be very long, is it? But if it is, then one can cache the value in host
byte order upon insertion into list... BTW, is original contributor on
the list? A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
