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.