On Tue, Oct 11, 2011 at 7:16 AM, Gisle Vanem gvanem@broadpark.no wrote:
The use of 'pid_t' confuses me a bit:
In common/procmon.c (inside MS_WINDOWS), it's typedef'ed to 'int' unconditionally.
And then in common/util.* (tor_terminate_process()) it is assumed to be defined in orconfig.h or somewhere else. It's not AFAICS.
It is true that _getpid() returns an 'int', but the way Tor uses it seems wrong; the last argument to OpenProcess() takes a 'DWORD'. So 'pid_t' should be 'DWORD' IMHO.
If that's what we're going to do, we should make sure that we don't use any posix-compatibility functions that return/expect an int pid, like _getpid(). So perhaps we should have a tor_pid_t that's a DWORD on windows and pid_t elsewhere, and we should stop using _getpid() in favor of GetCurrentProcessId, assuming that that's really what we ought to be calling.
So maybe we should introduce a 'typedef DWORD tor_pid_t;' in orconfig.h?
Well, if we add AC_TYPE_PID_T in configure.in, then we can make sure that pid_t is defined on autoconf-based builds, and we can define it to DWORD for MSVC builds in src/win32/orconfig.h. But I worry there: it's a little error-prone to have a type that is unsigned in some places and signed elsewhere. We should audit all our pid_t uses if we're going to try something like that.