pid_t is a POSIX standard type, and its definition specifies that it’s a "
Signed integer type".
In MinGW, regardless of the implementation, it is always an integer.
MinGW had once considered making pid_t a fixed-size 32-bit integer, but it was never implemented as a pointer.
While I understand that Windows has never actually implemented POSIX, considering that pid_t is a POSIX type after all, expressing it as a type that contradicts the POSIX definition is still a bit strange. This may cause some problems in cross-platform applications, especially considering that MinGW is currently the default stdc used by Zig on Windows, and MinGW, which implements pid_t, also implements it as an integer type.
fd_t may also have similar problems.
I never used pid_t in Zig so far, but actually I think pid_t ought to be a struct of its own, to make it clear that except from controlling other processes, there is nothing one can do with it, eg it doesn’t make sense to increment it or perform other arithmetic.
It might just be a simple mistake. A quick search suggests that mingw-w64 only uses it for two functions, sched_getscheduler() and sched_setscheduler(), and they pass it on to OpenProcess() which takes a DWORD process id and not a HANDLE, so the definition is misleading (even though it’s the correct size). I believe the long term plan is to gut the Windows parts out of the POSIX-y parts of std, but submitting a fix probably wouldn’t hurt.
However, may I ask why you are even using pid_t from std in the first place? The standard library itself doesn’t seem to expose those two functions when targeting Windows, and like you say it’s a POSIX extension and not part of standard C or the Windows API.
2 Likes
Yeah, pid_t = HANDLE originated a long time ago when the structure of the code was much different.
It probably hasn’t been revisited since it’s effectively unused at this point.
Thanks, this is probably because I’m used to programming on Windows using MinGW-w64 as the toolchain, which does some simple wrapping for the POSIX standard on Windows. When I learned that Zig uses MinGW as the default stdc, I wasn’t surprised that some POSIX extensions support Windows, because some extensions are indeed supported under MinGW.