Am 28.02.2016 um 18:04 schrieb David Grayson: > > This change would require a lot of 64-bit ingw-w64 libraries and > executables to be recompiled, and possibly require code changes, > right? Does the use of 64-bit ints for PIDs actually cause any bugs? > > --David >
Yes, it causes problems in QEMU for Windows because getpid() does return an int and pid_t is not int for 64 bit Windows. Of course it is possible to work around that problem. It's necessary to choose between fixing the problem at the source (Mingw-w64) which makes porting of POSIX code easier in the future but which possibly requires modifications for existing code using Mingw-w64. Or to keep the wrong type definition which means we'd need workarounds like the one in QEMU forever. :-( See this discussion: http://lists.nongnu.org/archive/html/qemu-devel/2015-09/msg06804.html In many cases existing libraries would still work with a new Mingw-w64 using 32 bit pid_t. They would expect a 64 bit pid, get a 32 bit pid, so the upper 32 bits would be undefined. This would not harm for most use cases, because typically that 64 bit pid is casted to a DWORD before using it because Windows only uses 32 bit pids. Only when the whole 64 bit pid is used (for example when printing the value) there would be a difference. Stefan PS. If you want, you can add QEMU to the project list http://mingw-w64.org/doku.php#some_projects_using_mingw-w64 ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
