[David Abrahams]
> Yes, but in the meantime, PyInt_AS_LONG( invoke_int_conversion(x) )
> might be a crash instead of raising an exception.
As the comment before that macro's definition says,
/* Macro, trading safety for speed */
PyInt_AsLong() won't crash, but its result needs to be checked for an error
return.
Note that your example:
PyInt_AS_LONG( invoke_int_conversion(x) )
wasn't safe before either: I'm not sure what invoke_int_conversion(x) means
exactly, but the plausible meanings I can think of for it *could* yield a
NULL pointer, or a pointer to a non-int object, in any version of Python
(e.g., PyNumber_Int() calls tp_as_number->nb_int but doesn't check the
return value for sanity). In either of those cases PyInt_AS_LONG blindly
applied to the result could crash.
> That's what is causing my test to fail. I guess I just need to lowercase
> a few characters,
You also need to check for an error return -- PyInt_AsLong() can fail.
> but it's worth noting that this change breaks existing
> extension module code.
I'm not sure it can break any I wouldn't have considered broken before.
It's normal (& expected) not to use the macro unless you *know* you've got
an int object, usually by virtue of passing a PyInt_Check() test first.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4