The SSL_set_fd and SSL_get_fd take an int as parameter for the socket. While this was fine on windows 32 bit and on all *nix variants (even 64 bit), this is not fine anymore on Windows 64 bit. I hope this can be fixed. Because a SOCKET on windows 64 bit is a UINT_PTR which is 64 bit while an int is only 32 bit (even 64 bit Windows).
Windows SOCKET is a handler to *kernel* object and as such constitutes an *offset* in per-process handle table. As this table can accommodate not more than 2^24 entries, it's always *safe* to cast/truncate SOCKET to 32-bit value and back. Even on 64-bit Windows.
Would it be possible to fix this in the coming releases ? Or is there any workaround for this ?
Formally there is nothing to fix, as the binary code will operate correctly, but it's understandable that compiler warning appears alarming. I don't want to say whether or not this warning will be addressed, but meanwhile explicitly cast argument or accept the warning. A.
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
