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 amcnabb
Recipients LambertDW, amcnabb, robertluce, theller
Date 2009-07-30.20:43:02
SpamBayes Score 0.0
Marked as misclassified No
Message-id <20090730204256.GB9602@mcnabbs.org>
In-reply-to <4A71F12E.70202@ctypes.org>
Content
On Thu, Jul 30, 2009 at 07:14:56PM +0000, Thomas Heller wrote:
> 
> Thanks for bringing my attention to this problem again, and for the review.

I'm just glad to help.

> The problem is that the patch changes the behaviour of the
> 'POINTER(...).from_param' methods, so I'm unsure if it can be applied
> to 2.6 (or even 2.5).  Opinions?

Hmm.  So you're saying that someone could be calling from_param() and
expecting to see 0 instead of None.  Am I understanding correctly?  I
suppose that could happen on either 32-bit or 64-bit systems (because
from_param returns 0 for both).  I can't personally think of a situation
where someone would rely on that, but maybe it's something to ask about
on python-dev.

I just looked at ConvParam in a little more detail, and it seems that
the problem is caused because setting pa->value.i to 0 only works for
the lower-order bits.  Apparently the higher order bits in pa->value are
non-zero when ConvParam is called.  Would it be possible to zero-out
pa->value at the top of ConvParam (i.e., putting "bzero(&(pa->value),
sizeof(pa->value)" or something at the top of ConvParam)?  Am I missing
something about what's in pa before ConvParam is called?

> The patch is missing a 'Py_INCREF(value)' before the 'return value;',
> but this is a minor point.

Thanks for pointing that out.  I'm still getting familiar with reference
counting in the Python API.
History
Date User Action Args
2009-07-30 20:43:05amcnabbsetrecipients: + amcnabb, theller, LambertDW, robertluce
2009-07-30 20:43:03amcnabblinkissue4606 messages
2009-07-30 20:43:03amcnabbcreate