On Mon, May 20, 2013 at 11:40 AM, Andrea Shepard wrote:
> There are plenty of archs where the virtual address space is larger than
> any single object can be; lots and lots of old real-mode x86 compilers,
> for example.
This is why I keep saying "(provided that the address space is flat)".
Pleas
On Sat, May 18, 2013 at 11:55:48AM -0400, Zack Weinberg wrote:
> There's nothing wrong with sizeof(long) == sizeof(int), but I assure
> you that C89 does require sizeof(long) >= sizeof(void *) [more
> precisely, that a valid value of type 'void*' can be cast to 'unsigned
> long' and back without lo
I don't think this conversation is going anywhere constructive, but I
wish to correct a factual error before I drop the subject.
> Really? where? It doesn't seem to be in the C89 standard I just flipped
> through.
You are quoting C99, not C89. The thing we are arguing about was
changed in the 1
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
> as you will rightfully point out because of things like windows returning -1
> but probably neglect things like redhat's patched-up version blowing up on
> invalid unicode sequences, etc.
clarified: windows snprintf() returning -1 on 0-length buffer inputs;
lacking nil-termination in some cases
> 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 to refuse to port to this platfor
> 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 t
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
On 2013-05-17 11:04 PM, Blibbet wrote:
On the positive side, it seems like many Win32 projects get about 15%
faster (when run on NT64 systems, removing the overhead of the Win32
subsystem)
Just one point of information: this is almost certainly due to the
larger register set and newer, more e
On 2013-05-17 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. There are literally hundreds
of thousands of warnings about integer truncation, at leas
> AFAIK, Tor has only been compiled as a Win32 app, never as a Win64 app.
More or less what I thought, tyvm.
> In the past, most of the time, Tor only builds on Windows with GCC/MinGW. But
> recently,
>Tor works primarily on Windows via MinGW toolchain, AFAIK still MinGW32. It
>has worked a few
> 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. [...]
...
AFAIK, Tor has only been compiled as a Win32 app, never as a Win64 app.
I realize that many/most/all of the develo
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. There are literally hundreds
of thousands of warnings about integer truncation, at least some of
which seem somewhat problemati
23 matches
Mail list logo
