> 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 majordomo@openssl.org