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.
for reference,
http://msdn2.micr
> > 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.
> for reference,
>> 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
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
Hi
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 i
