This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients christian.heimes, loewis, stutsman
Date 2008-02-01.19:18:26
SpamBayes Score 0.00039430795
Marked as misclassified No
Message-id <47A3707B.4050608@cheimes.de>
In-reply-to <47A2A871.7020205@v.loewis.de>
Content
Martin v. Löwis wrote:
> 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.

I added the size comparison to identify systems with sizeof(pid_t) >
sizeof(long).

> 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.

Your proposal looks sound and good to me, but it involves some work. The
chance would require a new format operator 'p' for argument parsing and
new functions like PyInt_FromPid_t() and PyInt_AsPid_t().

In r60504 I've changed the type for the remaining functions like waitpit
 and getsid to pid_t. It should make it easy to spot the lines that have
to be changed.

Christian
History
Date User Action Args
2008-02-01 19:18:33christian.heimessetspambayes_score: 0.000394308 -> 0.00039430795
recipients: + christian.heimes, loewis, stutsman
2008-02-01 19:18:27christian.heimeslinkissue1983 messages
2008-02-01 19:18:26christian.heimescreate