title: Is it safe to cast SOCKET to int under Win64?
body: <p>I’m working on a Windows port of a POSIX C++ program.</p>
  
  <p>The problem is that standard POSIX  functions like accept() or bind() expect an ‘int’ as the first parameter while its WinSock counterparts use ‘SOCKET’.<br>
  When compiled for 32-bit everything is fine, because both are 32bit, but under Win64 SOCKET is 64 bit and int remains 32 bit and it generates a lot of compiler warning like this:<br><br>
  <code>warning C4244: '=' : conversion from 'SOCKET' to 'int', possible loss of data</code></p>
  
  <p>I tried to work around the issue by using a typedef:</p>
  
  <pre><code>
  #ifdef _WIN32
   typedef SOCKET sock_t;
  #else
   typedef int sock_t;
  #endif
  </code></pre>  
  
  <p>and replacing ‘int’s with sock_t at the appropriate places.</p>
  
  <p>This was fine until I reached a part of the code which calls OpenSSL APIs.<br>
  As it turned out OpenSSL uses ints for sockets even on Win64. That seemed really strange, so I started searching for an answer, but the only thing I found was an old post on the openssl-dev mailing list which refered to a comment e_os.h:  </p>
  
  <pre><code>
  /*
   * Even though sizeof(SOCKET) is 8, it's safe to cast it to int, because
   * the value constitutes an index in per-process table of limited size
   * and not a real pointer.
   */
  </code></pre> 
  
  <p>So my question is:<br>
  is it really safe to cast SOCKET to int?<br><br>
  I’d like to see some kind of documentation which proves that values for SOCKET can't be larger than 2^32.<br><br>
  Thanks in advance!<br>
  Ryck  </p>