[issue1983] Return from fork() is pid_t, not int

Ryan Stutsman stuts...@stanford.edu added the comment: No, I don't think this is actually fixed in any version of Python at the moment. The title may be a bit misleading, because all the versions now store the result of fork in a pid_t and return it as a PyLong. However, posix_waitpid is still

[issue1983] Return from fork() is pid_t, not int

Ryan Stutsman added the comment: Actually the current trunk of as of this morning (60484) is still broken in a couple of ways. First, converting the pid_t using PyInt is a problem and second the waitpids aren't corrected. This would cause waits on invalid pids

[issue1983] Return from fork() is pid_t, not int

New submission from Ryan Stutsman: In current trunk (60097). Return from fork is not int but pid_t. Treating this as an int causes total breakage on systems with 64-bit pids. -- components: Library (Lib) messages: 61926 nosy: stutsman severity: normal status: open title: Return from

[issue1983] Return from fork() is pid_t, not int

Ryan Stutsman added the comment: Yeah; I shuold be able to provide one. I just hacked 2.4.4 to work so I think I could provide a fix easily. The version I put together here is rough, so I'll try to create a cleaner solution tonight or this weekend. HiStar does (http://www.scs.stanford.edu

[issue1983] Return from fork() is pid_t, not int

Ryan Stutsman added the comment: IIUC, HiStar is available in a 32-bit version, too, yet it may still use a 64-bit pid_t (Ryan, can you confirm whether that's the case?). Great point. pid_t is always 64-bit on HiStar. __ Tracker [EMAIL PROTECTED] http