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. It's not so much horrible omgbug because I'm hard pressed to think of much of an instance where it would blow up, but more of a "why would anyone even...?"
That intptr_t is just one of several thousand warnings relating to truncation, most are probably benign, but I'd call anyone who said with confidence that all of them are benign a fool. If we consider the use and intent of this application and that its is expected to be used on overly hostile networks with state-level intruders, you're just asking to end up with blood on your hands. I don't expect the 64-bit unix builds to be much/any better, especially with statements like the unsigned long<->pointer 64-bit ABI thing. Thats just dumb.
On Sat, May 18, 2013 at 12:01 AM, Zack Weinberg zackw@panix.com wrote:
On 2013-05-17 11:32 PM, not me wrote:
... using intptr_t as a return value for socket() ...
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.
(This is on my list of things to fix in libevent. Patches, um, hopefully in a couple months.)
zw
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev