Actually, C on VMS/Alpha knows very well what a long long is, and
knows how to make use of it. So let's stop pretending the Alpha
doesn't know long long...
And who said we were pretending? SIXTY_FOUR_BIT defines already BN_ULONG as long long...
--- openssl/makevms.com 11 Jul 2004 20:30:33 -0000 1.42 +++ openssl/makevms.com 6 May 2005 13:33:16 -0000 1.43 @@ -274,6 +274,7 @@ $ WRITE H_FILE "#endif" $! $ WRITE H_FILE "#if defined(HEADER_BN_H)" +$ WRITE H_FILE "#define BN_LLONG" $ WRITE H_FILE "#undef SIXTY_FOUR_BIT_LONG" $ WRITE H_FILE "#undef SIXTY_FOUR_BIT" $ WRITE H_FILE "#define SIXTY_FOUR_BIT"
BN_LLONG may not be defined along with SIXTY_FOUR_BIT, as it normally has devastating effect. It works on VMS/Alpha only thanks to inline BN_UMULT_HIGH assembler and shall stop working the moment you disengage it with no-asm [or whatever is equivalent on VMS]. If this is somehow is spinning around pqueue problem, then I find it more appropriate to eliminate dependancy from BN_ macros, rather than trying to squeeze it to where it doesn't belong in. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
