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