On Sat, 18 May 2013 at 17:24, Roger Dingledine wrote:
> Your relay launches reachability tests every 20 minutes, and it counts
> you as reachable if anybody succeeds at connecting (and making a Tor
> circuit) from the outside.
Ah, this could be it . This bridge[0] has notoriously _very_ low traffi
On Fri, May 17, 2013 at 11:11:33PM -0700, Christian Kujau wrote:
> Hm, an hour later it succeeded:
>
> May 17 20:40:43.000 [warn] Your server (...:9001) has not managed to confirm
> that its ORPort is reachable.
> May 17 21:00:43.000 [warn] Your server (...:9001) has not managed to confirm
> tha
Zack Weinberg once said:
> First, 'size_t' is required to be able to represent the size
> of any object;
Agreed.
> Second, 'size_t' is required to be no larger than 'unsigned long'.
Agreed.
> when the memory space is flat, this entails that 'void*' can
> be cast to 'size_t' and back without lo
> This is actually a normal and useful thing to do in C. (I think
> you're used to C++, where it is indeed much less useful due to the
> richer variety of abstractions.)
Actually, its pretty much always a horrible idea, if you're doing it,
you're asking for trouble. I wrote and reviewed C for ~10
> 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 h
> There's nothing wrong with sizeof(long) == sizeof(int),
Agreed.
> but I assure you that C89 does require sizeof(long) >= sizeof(void *)
Really? where? It doesn't seem to be in the C89 standard I just flipped through.
I flipped through it because this sounded horribly wrong. Here's what I found
> Neither of these is true.
I could accept it's been a while.
> For one, Tor builds fine for me, with no warnings, for me under
> mingw64. (I just tried it out to be sure, and used
> --enable-gcc-warnings to make sure I got all the weird fiddly
> warnings.)
I've not attempted with mingw for st
On Sat, May 18, 2013 at 12:44 AM, not me wrote:
>
> IMNSHO, its dense to even want to use pointers in this way. Why the
> hell are you converting pointers in this way in the first place, its
> just asking for a horrible mess.
This is actually a normal and useful thing to do in C. (I think
you're
On Sat, May 18, 2013 at 12:50 AM, not me 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
On Sat, May 18, 2013 at 11:19 AM, Anthony Martin wrote:
> Zack Weinberg once said:
>> * Win64 is the *only* flat-memory-space ABI ever promulgated in
>> which pointers cannot safely be converted to 'unsigned long'
>> and back without loss of information. This is a willful
>> violation of r
Zack Weinberg once said:
> * Win64 is the *only* flat-memory-space ABI ever promulgated in
> which pointers cannot safely be converted to 'unsigned long'
> and back without loss of information. This is a willful
> violation of requirements in C89 and is IMNSHO sufficient
> justification t
On Fri, May 17, 2013 at 10:07 PM, not me wrote:
> Hi,
>
> It seems fairly self-evident that tor hasn't been build for 64-bit
> windows and questionable whether it's ever been built in an
> environment that doesn't utilize mingw.
Neither of these is true.
For one, Tor builds fine for me, with no
In addition to Tor codebase, you also need to get external dependent
libraries working with Win64. LibEvent got some MinGW64 patches last
year, I believe. The OpenSSL binary distributions come in both Win32 and
Win64 versions. I'm not sure if base zlib has a working Win64 port, but
there's also
13 matches
Mail list logo
