We don't do this to increase the number of possible file descriptors that Tor can have open at the same time. We do it because under the hood Windows socket descriptors are kernel HANDLEs, thus *not* small positive integers, thus this part of winsock2.h:
You're right in the sense that I had a derp moment and forget that microsoft's socket() returns a handle and not a file descriptor.
#ifdef _WIN64 typedef UINT_PTR SOCKET; #else typedef u_int SOCKET; #endif
You're wrong in the sense that a UINT_PTR is not the same as an integer, or unsigned long if you prefer.
On Sat, May 18, 2013 at 12:29 PM, Zack Weinberg zackw@panix.com wrote:
On Sat, May 18, 2013 at 12:50 AM, not me anemenja@gmail.com wrote:
Look more closely at those libevent headers: this is only the case on Windows. Yeah, it's at least arguably wrong, but it's not interfering with anyone else.
why on earth anyone thought this was a good idea ever is beyond me. Even if we consider a 32-bit box with an OS that doesn't exist that allows me to approach 4B+ file descriptors open, we'd run out of address space trying to handle all of the data associated with each file.
We don't do this to increase the number of possible file descriptors that Tor can have open at the same time. We do it because under the hood Windows socket descriptors are kernel HANDLEs, thus *not* small positive integers, thus this part of winsock2.h:
/*
- The new type to be used in all
- instances which refer to sockets.
*/ #ifdef _WIN64 typedef UINT_PTR SOCKET; #else typedef u_int SOCKET; #endif
Ironically this appears to be one of the places where we *are* trying for Win64 compatibility.
Nick is probably right about why you're getting truncation errors over this.
zw _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev