MoonchildProductions#1251 - Part 3: Finally end the long tradition of casting getpid() to int.

https://bugzilla.mozilla.org/show_bug.cgi?id=535106
https://bugzilla.mozilla.org/show_bug.cgi?id=1359841

Like many parts of the busted Solaris support, this one has its origins in the pre-Firefox days. Bug 535106, another Mozilla suite bug. It keeps coming up because the core issue is never addressed, the fact that nsTSubstring doesn't know how to handle pid_t. I think the explicit cast to int is a band-aid they use because they know if they touch that substring header file to make it handle pid_t, they'll probably be asked to fix all the other problems with it. I honestly think it just works by accident on other platforms because it's implicitly cast to signed or unsigned int, even though the POSIX standard says pid_t can be either long or int, and work as either a signed or unsigned integer. Whatever the case may be, it's handled better on Solaris now than it was.

Ironically enough, the main point of having pid_t rather than just having pids be int or something is to hide this little implementation detail so you can just use pid_t for the return type in portable code without having to worry about what it is on a specific platform. The unfortunate way Mozilla implemented string functions turns that on its head and makes the good things about pid_t into liabilities rather than assets.

xpcom/base/nsTraceRefcnt.cpp

@@ -657,7 +657,7 @@ InitLog(const char* aEnvVar, const char* aMsg, FILE** aResult)
         fname.Append('_');
         fname.Append((char*)XRE_ChildProcessTypeToString(XRE_GetProcessType()));
         fname.AppendLiteral("_pid");
-        fname.AppendInt((uint32_t)getpid());
+        fname.AppendInt(getpid());
         if (hasLogExtension) {
           fname.AppendLiteral(".log");
         }