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 problematic (64-bit pointer being stored in a 32-bit integer (why?! why?!)), a small amount of signed/unsigned comparisons or sign extensions, and a bunch of calls to functions without including the proper header files or using the correct function name ('open()' vs '_open()' without including io.h) and so on.
This of course is ignoring all the calls to str{,n}cpy/{v,}s{,n}printf/etc and posix function names long since deprecated (fileno() vs _fileno()) and so on. Errors relating to MSVC finally including a stdint header (cstdint) and typedef's for intptr_t not producing the right size primitive, etc.
I realize that many/most/all of the developers here are going to see no problem with using mingw, but if you spend some time looking underneath the hood and reviewing the code generated by mingw v. msvc both in terms of security features and general performance, I can't feel that its a prudent or responsible choice to produce anything under windows using GNUs development tools. So I'd prefer to just eliminate all such 'fixes'.
Moving to 32-bit isn't an option either, I'd have to switch out far too many dependencies that frankly are a bit more important, and well I need 64-bit for some aspects and it's only been a decade since AMD released their first 64-bit chip.
So, has anyone out there successfully built tor with a 64-bit msvc, and if so, you don't happen to have a list of voodoo tricks you performed or a diff or similar?
Thanks.
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 developers here are going to see no problem with using mingw, but if you spend some time looking underneath the hood and reviewing the code generated by mingw v. msvc both in terms of security features and general performance, [...]
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 times in the past, in the last few weeks, another update was made for MSVC (Win32), and hopefully that still works with trunk.
Re: security, Tor has most of the modern exe image flags properly tweaked with GCC toolchain. But not with MSVC toolchain. IMO, that'd be a nice patch, for MSVC build. But not too serious since Tor doesn't ship any MSVC-based distros, only GCC-based ones, as public binaries.
I think the issue is not MSVC -vs- GCC, but Win32 -vs- Win64, if they're willing to take all those kinds of patches.
And the additional burden for them to distribute 2* the Windows packages, both Win32 and Win64.
It *might* be an issue that Thandy is also probably only Win32, and might also need to be ported, when updating the WIX/NSIS installer scripts (Thandy gets called from within some of those scripts).
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) ..at least looking at use of MSVC toolchain, unclear about MinGW64 toolchain. So there's a chance that these patches would mean Windows Tor perf could get 15% better on modern (NT64-based: all servers, most desktops, and some mobile devices) Windows boxen. :-)
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 times in the past, in the last few weeks, another update was made for MSVC (Win32), and hopefully that still works with trunk.
I'm in the process of fighting with it trying to get it to at least compile, I suspect it will blow up at run-time however. There has to be a lot of bugs lurking waiting for the right conditions even on the 64-bit builds for unices, there's just so much stuff like using intptr_t as a return value for socket() (is there even an OS that will allow me to have billions of file descriptors open at once?). If I get anything spectacular going, I'll post a diff or something, but I suspect I'm going to loop back into the docs and just work on something a little closer to my needs and bypass tor's code base all together.
Re: security, Tor has most of the modern exe image flags properly tweaked with GCC toolchain. But not with MSVC toolchain. IMO, that'd be a > nice patch, for MSVC build. But not too serious since Tor doesn't ship any MSVC-based distros, only GCC-based ones, as public binaries.
Well it's not just exe header flags, but the heuristics for reorganizing stack variables and similar is just vastly superior. I can't even count the number of times what should have been an exploitable bug wasn't or in trying to demonstrate vulnerable code I've had to resort to inline assembly, et cetera. It's really irresponsible of people to utilize mingw on a windows platform IMHO, MSFT research has put a lot of time and money into things and at least for the time being there's really not adequate replacement.
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) ..at least looking at use of MSVC toolchain, unclear about MinGW64 toolchain. So there's a chance that these patches would mean Windows Tor perf could get 15% better on modern (NT64-based: all servers, most desktops, and some mobile devices) Windows boxen. > :-)
That's a pretty compelling argument to me.
cheers.
On Fri, May 17, 2013 at 11:04 PM, Blibbet blibbet@gmail.com wrote:
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 developers here are going to see no problem with using mingw, but if you spend some time looking underneath the hood and reviewing the code generated by mingw v. msvc both in terms of security features and general performance, [...]
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 times in the past, in the last few weeks, another update was made for MSVC (Win32), and hopefully that still works with trunk.
Re: security, Tor has most of the modern exe image flags properly tweaked with GCC toolchain. But not with MSVC toolchain. IMO, that'd be a nice patch, for MSVC build. But not too serious since Tor doesn't ship any MSVC-based distros, only GCC-based ones, as public binaries.
I think the issue is not MSVC -vs- GCC, but Win32 -vs- Win64, if they're willing to take all those kinds of patches.
And the additional burden for them to distribute 2* the Windows packages, both Win32 and Win64.
It *might* be an issue that Thandy is also probably only Win32, and might also need to be ported, when updating the WIX/NSIS installer scripts (Thandy gets called from within some of those scripts).
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) ..at least looking at use of MSVC toolchain, unclear about MinGW64 toolchain. So there's a chance that these patches would mean Windows Tor perf could get 15% better on modern (NT64-based: all servers, most desktops, and some mobile devices) Windows boxen. :-)
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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
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
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
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
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 efficient calling conventions used on x86-64. I would expect OS overhead (whether or not from a "subsystem", which AIUI is a vestigial concept in modern Windows anyway) to be more or less the same in both modes.
If I am mistaken about this -- if Windows actually does offer substantially reduced OS overhead for 64-bit processes -- then, with my Firefox hat on rather than my Tor hat, I would really appreciate pointers to details.
zw
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 the zlib-Win64.GoogleCode that appears to be working on this problem.
Yes, it's a combo of API and OS subsystem simplification, not just subsystem. As for more information on perf, I seem to recall some MSFT VC++ white paper back when Win64 porting was a new thing, with some more details. And some commercial VS addon that helps migrate code from Win32 to Win64 also to have some case studies. Sorry, can't find URLs to either. It will be really interesting to see some perf data with your Win64 version of Tor!
For packaging, alternately, keep the normal number of packages, but make each one 2* the size, and update the installer to install the right version, and force all uses to download an unneeded version of Tor binary.
Long term, for the Tor codebase on Windows, besides 32- and 64-bit versions for Intel/AMD, also look into 32-bit ARM release. For Win8, for Win32-based OEM netbooks/tablets, perhaps even the MSFT Surface tablets (one is x86, one is ARM). WinPhone7 was too restricted to run Tor (or any Win32 app) on it. WinPhone8 can apparently run native Win32 C ARM code, but is still based on WinCE/WinMobile, no security, weird WinCE/WinMobile OS/libC hacks required. There's hope that NT will finally kill off CE, and that Windows Phone 9 or 10 will be based on NT not CE/WinMobile, likely 32-bit ARM-based. An ARM port is needed for any of these non-x86 platforms.
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 least some of which seem somewhat problematic (64-bit pointer being stored in a 32-bit integer (why?! why?!)), a small amount of signed/unsigned comparisons or sign extensions, and a bunch of calls to functions without including the proper header files or using the correct function name ('open()' vs '_open()' without including io.h) and so on.
This of course is ignoring all the calls to str{,n}cpy/{v,}s{,n}printf/etc and posix function names long since deprecated (fileno() vs _fileno()) and so on. Errors relating to MSVC finally including a stdint header (cstdint) and typedef's for intptr_t not producing the right size primitive, etc.
Please understand that we can turn every single one of these complaints on its head and make it a failing of Windows:
* 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 platform, all by itself.
* The POSIX functions 'open', 'close', 'fcntl', etc are not deprecated and do not have underscores in their names. That Windows provides headers that *purport* to provide a subset of POSIX functionality, but with all the symbols renamed (and claiming that the renames were necessary for C89 conformance, which is not true) can only be interpreted as a deliberate snub to people attempting to write code which runs on both Windows and Unix systems. It would have been more honest not to provide these functions at all.
* The "security enhanced" functions that I suspect you think we should be using are not actually a security enhancement over proper use of functions that already existed. In fact, most of the _s functions are just new, less-portable names for existing functions, sometimes with gratuitous and inconvenient interface changes on top. For instance, snprintf is secure when used correctly, and snprintf_s provides no additional benefit whatsoever. I will grant you that strcpy is easy to misuse, but I expect that if you check you will find that in *this* codebase it is used safely.
Now, I don't mean to discourage you by saying all that; I only want you to understand why the Windows port is not our favorite thing to hack on ourselves. We probably *would* take patches to allow Tor to build and operate correctly using current MSVC. I am not sure whether we would take patches to allow Tor to build as a Win64 program; it depends how invasive they are and whether it would make life harder for people maintaining other platforms.
It is not clear to me why you need Tor to be 64-bit. It runs as a separate process and acts as a local network proxy. It should be able to do that just fine for 64-bit processes while continuing to be 32-bit itself. Please clarify.
zw
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 platform, all by itself.
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. A long is not guaranteed to be the same size as a pointer, if you're doing this, you're doing it wrong and platforms that allow this are just enabling you to have very very bad habits. This is an area where years of horrible programming practices bit MSFT pretty hard because so many people went "derp DWORDs are the same size as pointers".
I don't think I've heard anyone cite C89 in years, although I understand many compilers/etc still don't meet C99 standards.
The POSIX functions 'open', 'close', 'fcntl', etc are not deprecated and do not have underscores in their names. That Windows provides headers that *purport* to provide a subset of POSIX functionality, but with all the symbols renamed (and claiming that the renames were necessary for C89 conformance, which is not true) can only be interpreted as a deliberate snub to people attempting to write code which runs on both Windows and Unix systems. It would have been more honest not to provide these functions at all.
Funny, I do it all the time without problem, of course I generally avoid standards like posix which despite saying its portable, actually isnt. Although TBF, osx is my big exception, as it feels more like writing c on a sunos 4 box than anything modern. Then again, I also get an easier out by preferring C++ anymore and making use of the STL which allows me to avoid a lot of related pitfalls (specifically thinking of file operations).
Either way, my biggest point there being that posix is better thought of as 'sorta kinda portable across some of the unices' than truly portable.
The "security enhanced" functions that I suspect you think we should be using are not actually a security enhancement over proper use of functions that already existed. In fact, most of the _s functions are just new, less-portable names for existing functions, sometimes with gratuitous and inconvenient interface changes on top. For instance, snprintf is secure when used correctly, and snprintf_s provides no additional benefit whatsoever. I will grant you that strcpy is easy to misuse, but I expect that if you check you will find that in *this* codebase it is used safely.
Well firstly, I am not referencing the _s() functions, although if you're only thinking about things like strcpy_s() you're sorta missing a lot of points, off-hand i dont think tor is multi-threaded, so a lot of them are moot. snprintf() is a horrible example, its a good place where you run into cross-platform issues, 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.
Either way, I wasn't referencing those so much as things like vastly superior heuristics at reordering variables, being especially careful with function pointers and putting them into registers, etc-- nevermind things like exception handling that doesnt negate all of the stack/heap/etc cookies, so on and so forth. Put quite simply, if you're using mingw to ship anything serious for a windows platform, you're being irresponsible with your users computers. MSVC express is free as in go download it now, so there's really no excuses anymore. This doesn't even touch that it's actually a better compiler in terms of the performance of the code generated.
Now, I don't mean to discourage you by saying all that; I only want you to understand why the Windows port is not our favorite thing to hack on > ourselves. We probably *would* take patches to allow Tor to build and operate correctly using current MSVC. I am not sure whether we would > take patches to allow Tor to build as a Win64 program; it depends how invasive they are and whether it would make life harder for people maintaining other platforms.
You didn't, if anything you encouraged me to review some of these bugs some more. Truthfully, if I am going to put the time and effort into this, it's probably better spent reading the specs and just rewriting things from the ground, tor is starting to feel like the x11 of privacy apps.
It is not clear to me why you need Tor to be 64-bit. It runs as a separate process and acts as a local network proxy. It should be able to do that just fine for 64-bit processes while continuing to be 32-bit itself. Please clarify.
I really hate this line of logic, look I get it that this code was written obviously sorta ad-hoc and targeted with only 32-bit in mind and that extending it to 64-bit has been a bit of a process and that the obvious advantages to most users are going to be mildly neglible and whatever performance increases they gained are going to be lost in the network, but it drives me nuts that the answer is for everyone just to stop using the full potential of their computer, more so, I'm not the typical user and will be dealing with very very large datasets and have requirements elsewhere (ie in the database) that just make it more of a project to inverse simply for tor than its worth.
Truth be told, I have very little interest in the overall package of tor, utilizing the proxy, or one of the million and one front-ends that really serve no purpose-- the interest in tor itself is the existing infrastructure, the network that already utilizes it. I was investigating the libonionrouter package, because when I saw it I thought 'finally! someone did all the heavy lifting and it wasnt me" and then realized it was just a wrapper around the tor code base, which is how I got here.
It's fine, I'll work it out on my own, I've lost to many hours of my life arguing with people who demand that everything feel like a very simple linux box rather than write their code properly, I have no interest in doing it again.
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. Redhat (at least some versions, didnt go pull down their patched up libc to validate its still like this) would always return the full length it would have written and can be made to blow up on some unicode sequences in some locales.
On Sat, May 18, 2013 at 12:44 AM, not me anemenja@gmail.com wrote:
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 platform, all by itself.
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. A long is not guaranteed to be the same size as a pointer, if you're doing this, you're doing it wrong and platforms that allow this are just enabling you to have very very bad habits. This is an area where years of horrible programming practices bit MSFT pretty hard because so many people went "derp DWORDs are the same size as pointers".
I don't think I've heard anyone cite C89 in years, although I understand many compilers/etc still don't meet C99 standards.
The POSIX functions 'open', 'close', 'fcntl', etc are not deprecated and do not have underscores in their names. That Windows provides headers that *purport* to provide a subset of POSIX functionality, but with all the symbols renamed (and claiming that the renames were necessary for C89 conformance, which is not true) can only be interpreted as a deliberate snub to people attempting to write code which runs on both Windows and Unix systems. It would have been more honest not to provide these functions at all.
Funny, I do it all the time without problem, of course I generally avoid standards like posix which despite saying its portable, actually isnt. Although TBF, osx is my big exception, as it feels more like writing c on a sunos 4 box than anything modern. Then again, I also get an easier out by preferring C++ anymore and making use of the STL which allows me to avoid a lot of related pitfalls (specifically thinking of file operations).
Either way, my biggest point there being that posix is better thought of as 'sorta kinda portable across some of the unices' than truly portable.
The "security enhanced" functions that I suspect you think we should be using are not actually a security enhancement over proper use of functions that already existed. In fact, most of the _s functions are just new, less-portable names for existing functions, sometimes with gratuitous and inconvenient interface changes on top. For instance, snprintf is secure when used correctly, and snprintf_s provides no additional benefit whatsoever. I will grant you that strcpy is easy to misuse, but I expect that if you check you will find that in *this* codebase it is used safely.
Well firstly, I am not referencing the _s() functions, although if you're only thinking about things like strcpy_s() you're sorta missing a lot of points, off-hand i dont think tor is multi-threaded, so a lot of them are moot. snprintf() is a horrible example, its a good place where you run into cross-platform issues, 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.
Either way, I wasn't referencing those so much as things like vastly superior heuristics at reordering variables, being especially careful with function pointers and putting them into registers, etc-- nevermind things like exception handling that doesnt negate all of the stack/heap/etc cookies, so on and so forth. Put quite simply, if you're using mingw to ship anything serious for a windows platform, you're being irresponsible with your users computers. MSVC express is free as in go download it now, so there's really no excuses anymore. This doesn't even touch that it's actually a better compiler in terms of the performance of the code generated.
Now, I don't mean to discourage you by saying all that; I only want you to understand why the Windows port is not our favorite thing to hack on > ourselves. We probably *would* take patches to allow Tor to build and operate correctly using current MSVC. I am not sure whether we would > take patches to allow Tor to build as a Win64 program; it depends how invasive they are and whether it would make life harder for people maintaining other platforms.
You didn't, if anything you encouraged me to review some of these bugs some more. Truthfully, if I am going to put the time and effort into this, it's probably better spent reading the specs and just rewriting things from the ground, tor is starting to feel like the x11 of privacy apps.
It is not clear to me why you need Tor to be 64-bit. It runs as a separate process and acts as a local network proxy. It should be able to do that just fine for 64-bit processes while continuing to be 32-bit itself. Please clarify.
I really hate this line of logic, look I get it that this code was written obviously sorta ad-hoc and targeted with only 32-bit in mind and that extending it to 64-bit has been a bit of a process and that the obvious advantages to most users are going to be mildly neglible and whatever performance increases they gained are going to be lost in the network, but it drives me nuts that the answer is for everyone just to stop using the full potential of their computer, more so, I'm not the typical user and will be dealing with very very large datasets and have requirements elsewhere (ie in the database) that just make it more of a project to inverse simply for tor than its worth.
Truth be told, I have very little interest in the overall package of tor, utilizing the proxy, or one of the million and one front-ends that really serve no purpose-- the interest in tor itself is the existing infrastructure, the network that already utilizes it. I was investigating the libonionrouter package, because when I saw it I thought 'finally! someone did all the heavy lifting and it wasnt me" and then realized it was just a wrapper around the tor code base, which is how I got here.
It's fine, I'll work it out on my own, I've lost to many hours of my life arguing with people who demand that everything feel like a very simple linux box rather than write their code properly, I have no interest in doing it again.
On Sat, May 18, 2013 at 12:44 AM, not me anemenja@gmail.com 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 used to C++, where it is indeed much less useful due to the richer variety of abstractions.)
Without having looked into this in much detail, I suspect that most of the cases where this comes up in Tor are due to passing a numeric value as data to a callback API that's specified in terms of void*. Note that this is strictly speaking casting an _integer_ to a _pointer_ and back and expecting this not to lose information, but the compiler can't tell which way round it's being done.
A long is not guaranteed to be the same size as a pointer
A long _was_ guaranteed to be _at least as large as_ a pointer in C89, and Microsoft still claims conformance to C89, not to any newer version of the C standard, despite this willful violation. (It is not a C99 violation. See my other message.)
if you're doing this, you're doing it wrong
I think if you read the code you will find that there is no better way to do what it is doing in C.
[re POSIX]
Funny, I do it all the time without problem, of course I generally avoid standards like posix which despite saying its portable, actually isnt. Although TBF, osx is my big exception, as it feels more like writing c on a sunos 4 box than anything modern. Then again, I also get an easier out by preferring C++ anymore and making use of the STL which allows me to avoid a lot of related pitfalls (specifically thinking of file operations).
Your experience is precisely the opposite of mine, then. POSIX.1-2001 functionality, including most of its optional bits, is reliably available and correct everywhere except Windows in my experience. OSX does give me grief sometimes but generally only due to its insistence on doing shared libraries differently from everyone else. And the STL is nice and all but I don't think the C++ standard library *has* any filesystem stuff other than iostreams, which are not particularly helpful (maybe they added something in C++11?)
...
Either way, I wasn't referencing those so much as things like vastly superior heuristics at reordering variables, being especially careful with function pointers and putting them into registers, etc-- nevermind things like exception handling that doesnt negate all of the stack/heap/etc cookies, so on and so forth. Put quite simply, if you're using mingw to ship anything serious for a windows platform, you're being irresponsible with your users computers. MSVC express is free as in go download it now, so there's really no excuses anymore. This doesn't even touch that it's actually a better compiler in terms of the performance of the code generated.
I can't really comment on this not having looked at codegen differences in detail, but I think the benefits of much of this hardening stuff are wildly overblown. Are you familiar with the current state of the art in bypassing them?
Anyway, like Nick I would be happy to see MSVC support patches. I suggest you look into the possibility of using the existing autotools-based build system to drive MSVC; I understand that this is supported in the latest automake, and it would mean that the build harness is much less likely to bitrot. You would still need the MSYS environment to run the build in, but you wouldn't be using their C compiler.
It is not clear to me why you need Tor to be 64-bit. It runs as a separate process and acts as a local network proxy. It should be able to do that just fine for 64-bit processes while continuing to be 32-bit itself. Please clarify.
I really hate this line of logic, look I get it that this code was written obviously sorta ad-hoc and targeted with only 32-bit in mind and that extending it to 64-bit has been a bit of a process and that the obvious advantages to most users are going to be mildly neglible and whatever performance increases they gained are going to be lost in the network, but it drives me nuts that the answer is for everyone just to stop using the full potential of their computer
I use "this line of logic" to try to decide on priorities. We obviously like the idea of that 15% performance gain due to the bigger register set, if it pans out, and there are other known concrete benefits to going 64-bit (better ASLR entropy, higher-performance cryptographic primitives in OpenSSL, that sort of thing) but we don't know if it's worth sinking a bunch of developer time into it compared to other things we could be doing. If there is a specific thing that you can't do right now because the program runs as 32-bit (and not just because that makes it slower) then suddenly 64-bit builds are more interesting.
more so, I'm not the typical user and will be dealing with very very large datasets and have requirements elsewhere (ie in the database) that just make it more of a project to inverse simply for tor than its worth. Truth be told, I have very little interest in the overall package of tor, utilizing the proxy, or one of the million and one front-ends that really serve no purpose-- the interest in tor itself is the existing infrastructure, the network that already utilizes it. I was investigating the libonionrouter package, because when I saw it I thought 'finally! someone did all the heavy lifting and it wasnt me" and then realized it was just a wrapper around the tor code base, which is how I got here.
It would help us understand where you're coming from if you talk a little about your larger goals. What are you trying to do for which the existing network of Tor nodes is useful but the existing software is not fit for purpose?
zw
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 years before deciding that actually C++ made way more sense in basically every case. That said, the computer you're using right now has code I've worked on, starting from it's processor working on up to its OS and likely with several applications in between. You can even dig through the US-CERT portal and find old papers I wrote giving guidance to them before they decided to slum it up at the edu's.
Without having looked into this in much detail, I suspect that most of the cases where this comes up in Tor are due to passing a numeric value as data to a callback API that's specified in terms of void*. Note that this is strictly speaking casting an _integer_ to a _pointer_ and back and expecting this not to lose information, but the compiler can't tell which way round it's being done.
A long is not guaranteed to be the same size as a pointer
A long _was_ guaranteed to be _at least as large as_ a pointer in C89, and Microsoft still claims conformance to C89, not to any newer version of the C standard, despite this willful violation. (It is not a C99 violation. See my other message.)
No it isn't, go read the standard you keep citing, take particular note of the annex of warnings where it tells you that this will result in truncation. You shouldn't even HAVE to look at the standard, you should be able to get some of these things simply by understanding the code you're writing. Simply imagining things into the c standard doesn't make it true.
I think if you read the code you will find that there is no better way to do what it is doing in C.
/tapsYourComputer I can virtually guarantee I've reviewed way more C/C++ than most people and probably yourself. It's what I've done for a living for well over a decade now and at this point you basically cannot use a modern computer without having components I've reviewed. Hey, I even have lines in the tor changelog for pointing out bugs 5-6 years back (or did-- I didn't actually report them, another I told about them did and included my name).
Your experience is precisely the opposite of mine, then. POSIX.1-2001 functionality, including most of its optional bits, is reliably available and correct everywhere except Windows in my experience. OSX does give me grief sometimes but generally only due to its insistence on doing shared libraries differently from everyone else.
More or less fair enough/agreed, although from memory OSX still has braindead issues like blowing up if you include some headers in the wrong order and similar.
And the STL is nice and all but I don't think the C++ standard library *has* any filesystem stuff other than iostreams, which are not particularly helpful (maybe they added something in C++11?)
Well, I think they would cover like 90% of the "issues" resulting from file interfaces in tor (albeit agreed benign ones).
I can't really comment on this not having looked at codegen differences in detail, but I think the benefits of much of this hardening stuff are wildly overblown. Are you familiar with the current state of the art in bypassing them?
I'm the guy who brought you how to bypass glibc's double free protections, pointed out how useful use-after-free's were going to be, downed google servers to show how scripting can be used to bypass ASLR, and disclosed the base problems in windows ASLR that led to a complete break of its implementation. Pretty sure I know them better than most, likely inclusive of yourself.
There's really no need to spam the list with dick measuring contests, if you really wish to continue, feel free to mail me directly.
Zack Weinberg zackw@panix.com 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 to refuse to port to this platform, all by itself.
This is just wrong. There's nothing wrong with having long be the same size as int. And Windows isn't the only 64-bit platform that does it. Plan 9 works the same way.
C89 explicitly says that even the mapping from pointer to integer types is implementation-dependent.
Anthony
On Sat, May 18, 2013 at 11:19 AM, Anthony Martin ality@pbrane.org wrote:
Zack Weinberg zackw@panix.com 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 to refuse to port to this platform, all by itself.
This is just wrong. There's nothing wrong with having long be the same size as int. And Windows isn't the only 64-bit platform that does it. Plan 9 works the same way.
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 loss of information] provided also that the memory space is flat. It is not itself a spelled-out requirement in the standard, but it follows from two requirements which are explicitly stated. First, 'size_t' is required to be able to represent the size of any object; when the memory space is flat, this entails that 'void*' can be cast to 'size_t' and back without loss of information. Second, 'size_t' is required to be no larger than 'unsigned long'.
For further exposition, please see comp.std.c archives in the time period leading up to C99. This was argued over in great detail because Microsoft forced the C committee to remove the second of the above two requirements from C99, over basically everyone else's objections, precisely so they could say the Win64 ABI wasn't a C conformance violation, *and then didn't implement any of the C99 features that would have made this less of a catastrophe for people trying to write portable code*. <stdint.h> was only added to MSVC in the 2010 edition (and only because C++ picked it up); there's still no <inttypes.h> and you still can't use %zu in printf.
Yes, I am still bitter. zw
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:
"7.18.1.4 Integer types capable of holding object pointers
1 The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:
intptr_t
The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:
uintptr_t
These types are optional."
Moreover, there is a warning in annex I relating to truncation when converting long/int/etc to a pointer of anything other than char* and vice versa.
In other words, I think you've imagined this requirement.
[more precisely, that a valid value of type 'void*' can be cast to 'unsigned long' and back without loss of information]
The phrase 'void*' doesnt appear in C89, all references to 'pointer to void', or 'void *'. Furthermore of the 44 references to unsigned long in C89, not a single one even references pointers to void, much less this absolutely absurd notion you have that converting pointers to integer types is safe and good programming practice.
It is not itself a spelled-out requirement in the standard, [....]
so our absolute guarantee that its in the standard is actually you reading between the lines?
but it follows from two requirements which are explicitly stated. First, 'size_t' is required to be able to represent the size of any object;
Indeed, why do we even need a size_t, we have an unsigned long!
Second, 'size_t' is required to be no larger than 'unsigned long'.
Not sure if you're saying that this is in the standard or if MSFT used its evil tentacles to have its removed, but no, the standard says its size is implementation defined. I *think* what you're referencing is possible this:
"The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary."
"supports objects large enough to make this necessary" AKA 64-bit.
and you still can't use %zu in printf.
You can't use %n either
Yes, I am still bitter.
Wrong people usually are.
On Sat, May 18, 2013 at 11:55 AM, Zack Weinberg zackw@panix.com wrote:
On Sat, May 18, 2013 at 11:19 AM, Anthony Martin ality@pbrane.org wrote:
Zack Weinberg zackw@panix.com 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 to refuse to port to this platform, all by itself.
This is just wrong. There's nothing wrong with having long be the same size as int. And Windows isn't the only 64-bit platform that does it. Plan 9 works the same way.
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 loss of information] provided also that the memory space is flat. It is not itself a spelled-out requirement in the standard, but it follows from two requirements which are explicitly stated. First, 'size_t' is required to be able to represent the size of any object; when the memory space is flat, this entails that 'void*' can be cast to 'size_t' and back without loss of information. Second, 'size_t' is required to be no larger than 'unsigned long'.
For further exposition, please see comp.std.c archives in the time period leading up to C99. This was argued over in great detail because Microsoft forced the C committee to remove the second of the above two requirements from C99, over basically everyone else's objections, precisely so they could say the Win64 ABI wasn't a C conformance violation, *and then didn't implement any of the C99 features that would have made this less of a catastrophe for people trying to write portable code*. <stdint.h> was only added to MSVC in the 2010 edition (and only because C++ picked it up); there's still no <inttypes.h> and you still can't use %zu in printf.
Yes, I am still bitter. zw _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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 1999 revision.
The closest approximation to C89 that I can find online is http://flash-gordon.me.uk/ansi.c.txt (this appears to be the text of the 1998 ANSI standard for C that was adopted by ISO one year later, extensively renumbered but with no substantive changes on the points of dispute). Please take note of the following differences from the later standard:
* There is no [u]intptr_t. * There is no such thing as an "extended integer type". The only "integral types" are [unsigned] char, [unsigned] short, [unsigned] int, and [unsigned] long. * size_t and ptrdiff_t are required to be "integral types", i.e. they *cannot* be larger than [unsigned] long. * Annex I does not exist. However, there is similar wording in section 3.3.4 (cast operators), stating that the result of converting any pointer to an integer is implementation-defined and that "if the space provided is not long enough, the behavior is undefined."
It is true that you will not find text anywhere in the 1989 standard explicitly stating that void* is required to be interconvertible with size_t (and therefore also with unsigned long) without loss of information. However, this point was debated extensively on comp.std.c in the late 1990s, with WG14 members participating, and the conclusion of that debate was that this *is* an implicit requirement of the 1989 standard (provided the memory space is flat), although not the 1999 standard.
The requirements of the older standard are still relevant precisely because Microsoft never implemented the newer standard. If they had, Tor would be using <stdint.h> and uintptr_t and you would not have had a problem in the first place. But they didn't. MSVC 2012 still claims conformance with "ANSI C" and "ISO C95", not C99: see http://msdn.microsoft.com/en-us/library/sk54f3f5.aspx (The only differences between C89 and C95 have to do with internationalization.)
zw
Zack Weinberg zackw@panix.com 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 loss of information
This is the part I disagree with. It's a non-portable assumption and the standard makes no such guarantee. The relevant sections concerning casts from integral types to pointer types are full of implementation-defined caveats. Imagine a system where you only have access to a flat 32-bit address space and size_t is 32 bits but where pointers are 33 bits with the top bit always set. Useless as it may be, this would still conform to C89.
Integer to pointer conversions should be handled with care. Systems where long has the same size as a pointer lead to carelessness in my opinion. ☺
Cheers, Anthony
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 loss of information] provided also that the memory space is flat. It is not itself a spelled-out requirement in the standard, but it follows from two requirements which are explicitly stated. First, 'size_t' is required to be able to represent the size of any object; when the memory space is flat, this entails that 'void*' can be cast to 'size_t' and back without loss of information. Second, 'size_t' is required to be no larger than 'unsigned long'.
No, just no. It requires that sizeof(void *) can be cast to size_t. 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. There are explicitly standards-conforming archs where pointer types can have sizes (a) dependent on the target type of the pointer and (b) larger than any integer type. For examples of weird pointers:
http://c-faq.com/null/machexamp.html
On Mon, May 20, 2013 at 11:40 AM, Andrea Shepard andrea@torproject.org 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)". Please, everyone who doesn't believe this really seriously was required by C89 -- go read the comp.std.c archives from 1997-1999! I'm not making this shit up.
zw
On Fri, May 17, 2013 at 10:07 PM, not me anemenja@gmail.com 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 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.)
For the other, there's been an nmakefile for ages now. That would seem to suggest that an msvc build has happened at least once. It doesn't get updated too often, because msvc users don't test or send patches very often.
There are literally hundreds of thousands of warnings about integer truncation, at least some of which seem somewhat problematic (64-bit pointer being stored in a 32-bit integer (why?! why?!)),
I bet you didn't edit src/win32/orconfig.h ? Ordinarily, autoconf would be setting all the types right for you, but if it isn't there, you need those defines to be right for your platform. For example, I bet that you've still got a #define SIZEOF_VOID_P 4 in there.
A patch to add an appropriate set of #ifdefs for win64 to src/win32/orconfig.h would be welcome.
a small amount of signed/unsigned comparisons or sign extensions,
Those I'd like to fix, if they turn out to be real once the orconfig.h issues are fixed.
and a bunch of calls to functions without including the proper header files or using the correct function name ('open()' vs '_open()' without including io.h) and so on.
Clean patches would be welcome here.
This of course is ignoring all the calls to str{,n}cpy/{v,}s{,n}printf/etc and posix function names long since deprecated (fileno() vs _fileno()) and so on. Errors relating to MSVC finally including a stdint header (cstdint) and typedef's for intptr_t not producing the right size primitive, etc.
strncpy and vsnprinf and fileno aren't deprecated in my world.
That said, I would sure not object to somebody doing the requisite work to make Tor build happily and warning-free under msvc and under msvc for windows 64, and I'd be happy to take whatever clean patches come out of this.
(I keep saying "clean" to emphasize that I'm *not* going to take patches that break other operating systems or compilers or older versions of msvc, and I'm *not* going to take patches that litter the code with #ifdefs in every single function that makes a syscall. I shouldn't have to say this, but I've gotten a lot of patches like that over the years.)
peace,
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 stated reasons. I'd have to question gcc's warnings here, there's lots of size_t to signed int, or size_t to uint16_t, or intptr_t to signed int, size_t to ssize_t, comparisons between signed and unsigned, etc. Without argument a lot/most/whatever are going to be benign, but with the volume of them and especially instances where a pointer is being converted to an integer type makes me think that at least some of them should be checked out and modified if necessary. I'd guess that whatever the flags being passed, they're actually not turning on some/many of gcc's warnings, but that's just a guess.
For the other, there's been an nmakefile for ages now. That would seem to suggest that an msvc build has happened at least once. It doesn't get updated too often, because msvc users don't test or send patches very often.
Indeed, go ahead and pop it open with msvc2012 and give it a shot.
I bet you didn't edit src/win32/orconfig.h ? Ordinarily, autoconf would be setting all the types right for you, but if it isn't there, you need those defines to be right for your platform. For example, I bet that you've still got a #define SIZEOF_VOID_P 4 in there.
I did, the first thing I had to fix was all the typedef's for intptr_t, however no, I haven't taken the time/initiative to go through the entire file and you're almost certainly correct about defines for void*.
A patch to add an appropriate set of #ifdefs for win64 to src/win32/orconfig.h would be welcome.
I spent some time going through the specs last night and it looks like just writing my own code is the easiest path, all I actually need is client code.
strncpy and vsnprinf and fileno aren't deprecated in my world.
posix vs. ISO
That said, I would sure not object to somebody doing the requisite work to make Tor build happily and warning-free under msvc and under msvc for windows 64, and I'd be happy to take whatever clean patches come out of this.
I believe this is going to also be a msvc 2010/2008 vs msvc 2012 thing, for instance as I said, they finally decided that having a stdint header was a good idea and it seems like some warnings are now errors and they've generally cleaned up their conformance a lot. This last part is a guess of mine and not really based on any large volume of methodical study, and of course could be wrong.
(I keep saying "clean" to emphasize that I'm *not* going to take patches that break other operating systems or compilers or older versions of msvc, and I'm *not* going to take patches that litter the code with #ifdefs in every single function that makes a syscall. I shouldn't have to say this, but I've gotten a lot of patches like that over the years.)
I totally agree with this sentiment, although I giggled a little at the ifdef's thing. Either way, as I said, the amount of work required exceeds what I at least perceive writing a some simple client functionality of my own would be. What I need is libonionrouter, not so much the entire tor package. all I really need to do is talk to/parse data from directories and build a circuit. I'm fairly positive the amount of code requisite there is far less than reading through/understanding and modifying hundreds/thousands? of lines of code. Best of luck with everything.
On Sat, May 18, 2013 at 10:43 AM, Nick Mathewson nickm@alum.mit.edu wrote:
On Fri, May 17, 2013 at 10:07 PM, not me anemenja@gmail.com 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 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.)
For the other, there's been an nmakefile for ages now. That would seem to suggest that an msvc build has happened at least once. It doesn't get updated too often, because msvc users don't test or send patches very often.
There are literally hundreds of thousands of warnings about integer truncation, at least some of which seem somewhat problematic (64-bit pointer being stored in a 32-bit integer (why?! why?!)),
I bet you didn't edit src/win32/orconfig.h ? Ordinarily, autoconf would be setting all the types right for you, but if it isn't there, you need those defines to be right for your platform. For example, I bet that you've still got a #define SIZEOF_VOID_P 4 in there.
A patch to add an appropriate set of #ifdefs for win64 to src/win32/orconfig.h would be welcome.
a small amount of signed/unsigned comparisons or sign extensions,
Those I'd like to fix, if they turn out to be real once the orconfig.h issues are fixed.
and a bunch of calls to functions without including the proper header files or using the correct function name ('open()' vs '_open()' without including io.h) and so on.
Clean patches would be welcome here.
This of course is ignoring all the calls to str{,n}cpy/{v,}s{,n}printf/etc and posix function names long since deprecated (fileno() vs _fileno()) and so on. Errors relating to MSVC finally including a stdint header (cstdint) and typedef's for intptr_t not producing the right size primitive, etc.
strncpy and vsnprinf and fileno aren't deprecated in my world.
That said, I would sure not object to somebody doing the requisite work to make Tor build happily and warning-free under msvc and under msvc for windows 64, and I'd be happy to take whatever clean patches come out of this.
(I keep saying "clean" to emphasize that I'm *not* going to take patches that break other operating systems or compilers or older versions of msvc, and I'm *not* going to take patches that litter the code with #ifdefs in every single function that makes a syscall. I shouldn't have to say this, but I've gotten a lot of patches like that over the years.)
peace,
Nick _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Andrea Shepard -
Anthony Martin -
Blibbet -
Nick Mathewson -
not me -
Zack Weinberg