[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev