[tor-dev] building from source in a 64-bit windows environment..

[not me]

> 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 at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev