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 theller
Recipients LambertDW, amcnabb, robertluce, theller
Date 2009-07-31.19:34:30
SpamBayes Score 1.110223e-16
Marked as misclassified No
Message-id <1249068872.87.0.697493317365.issue4606@psf.upfronthosting.co.za>
In-reply-to
Content
Andrew McNabb schrieb:
> 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?

Zeroing out higher order bits wouldn't help because the parameter would
still be passed as int instead as pointer; see the ffi_type field.

However, after thinking the whole issue over for some time I'm now
convinced that this patch is the right approach; even if .from_param()
returns 'None' instead of '0' the former should be accepted as well
because it better represents a NULL pointer anyway.

So I will apply the patch to trunk and 2.6, and forward port to the
python3 branches.  After further testing.
History
Date User Action Args
2009-07-31 19:34:33thellersetrecipients: + theller, amcnabb, LambertDW, robertluce
2009-07-31 19:34:32thellersetmessageid: <1249068872.87.0.697493317365.issue4606@psf.upfronthosting.co.za>
2009-07-31 19:34:31thellerlinkissue4606 messages
2009-07-31 19:34:30thellercreate