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

[not me]

> 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 at 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.