Message61947
| Author |
loewis |
| Recipients |
christian.heimes, loewis, stutsman |
| Date |
2008年02月01日.05:04:51 |
| SpamBayes Score |
0.0029030566 |
| Marked as misclassified |
No |
| Message-id |
<47A2A871.7020205@v.loewis.de> |
| In-reply-to |
<1201820979.09.0.06635507204.issue1983@psf.upfronthosting.co.za> |
| Content |
> Do you want to port the fix to 2.5?
I'm not quite sure that the patch actually fixes the
problem. 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?).
If so, Python would now fail to compile under that
patch. Backporting a change that causes Python to fail
to compile on some systems is not a good idea.
If that aspect was fixed also (e.g. by always returning
long ints on systems where sizeof(pid_t)>sizeof(long)),
a backport would be ok. For a perfect backport, that
change might still cause a behavior change: on
a system where sizeof(pid_t)>sizeof(long), yet the
system only ever uses pid_t values < INT_MAX, people
would see that the fork return type changes unreasonably;
a perfect backport would only return longs if the values
are out of range. This is probably over-cautious, as
it's fairly unlikely that such systems actually exist. |
|