I've now got OpenSSL 0.6.9h compiling and testing fine using Watcom
11.0c under Win2k, as a static library with and without the optimized
assembly. In the process, I've come across a few minor problems:
.\crypto\des\ecb_enc.c(96): Warning! W201: Unreachable code
if (sizeof(DES_LONG) != sizeof(long))
size="int";
else
size="long";
.\crypto\bio\bss_bio.c(819): Warning! W124: Comparison result always 0
if (ret > INT_MAX)
return INT_MAX;
else
return (int) ret;
.\crypto\bio\bss_bio.c(852): Warning! W124: Comparison result always 0
if (ret > INT_MAX)
return INT_MAX;
else
return (int) ret;
For a 64-bit platform, and/or one where an int isn't the same as a long,
the code makes sense. However, for WIN32 where an int is the same as a
long (I believe), the compiler correctly issues some warnings. I suggest
a simple fix, such as:
#ifndef WIN32
if (sizeof(DES_LONG) != sizeof(long))
size="int";
else
#endif
size="long";
I've also come across a not-so-minor problem, namely the calling
convention for the ASM functions. Unlike VC (and Borland?), Watcom
doesn't default to using the __cdecl convention (all arguments on
stack), but instead to its own register-based convention. This is not a
problem when no ASM is used, but because the ASM assumes a __cdecl
calling convention, the prototypes for the ASM functions have to be
declared with __cdecl in order for the linker to get things right. What
I propose is a macro to describe the calling convention under Windows,
along the lines of:
(in bn.h)
#if defined WIN32 && defined BN_ASM
#define CALLCONV __cdecl
#else
#define CALLCONV
#endif
....
BN_ULONG CALLCONV bn_mul_add_words(BN_ULONG *rp, BN_ULONG *ap, int num,
BN_ULONG w);
This shouldn't break things, it will allow Watcom to use its normal
register calling convention, and has the added benefit that VC users can
compile OpenSSL with __fastcall as the default (the VC register-based
calling convention). So, in theory, an all-round improvement for Windows
users.
I understand that 0.9.6h is supposed to be the last version of 0.9.6,
but I've started with that because I need a stable version of OpenSSL
for my application. Now that I have that, I intend to start testing
0.9.7, and I believe that all the issues I've described apply equally to
0.9.7. Therefore, I'd appreciate any comments and suggestions on this so
that I can submit an acceptable patch for the next release.
-C
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
