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

[not me]

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