Thomas Heller <thel...@ctypes.org> added the comment: 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. ---------- resolution: -> accepted versions: +Python 2.7, Python 3.0, Python 3.1, Python 3.2 -Python 2.5 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4606> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
