On Tue, Oct 11, 2011 at 7:16 AM, Gisle Vanem <[email protected]> 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. -- Nick _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
