Nick Coghlan, 02.03.2012 14:22: > On Fri, Mar 2, 2012 at 10:55 PM, Stefan Krah wrote: >> Nick Coghlan wrote: >>> However, given the lack of control, an assert() isn't the appropriate >>> tool here - PyObject_GetBuffer itself should be *checking* the >>> constraint and then reporting an error if the check fails. Otherwise a >>> misbehaving extension module could trivially crash the Python >>> interpreter by returning a bad Py_buffer. >> >> I'm not so sure. Extension modules that use the C-API in wrong or >> undocumented ways can always crash the interpreter. This assert() >> should be triggered in the first unit test of the module. Now, if >> the module does not have unit tests or they don't test against a >> new Python version is that really our problem? > > Crashing out with a C assert when we can easily give them a nice > Python traceback instead is unnecessarily unfriendly. As Stefan Behnel > pointed out, by tightening up the API semantics, we're already running > the risk of breaking applications that relied on looking at what the > old code *did*, since it clearly deviated from both spec (the PEP) and > the documentation (which didn't explain how ReleaseBuffer works at > all). > >> Modules do need to be recompiled anyway due to the removal of >> Py_buffer.smalltable, otherwise they will almost certainly crash. > >> Perhaps an addition to whatsnew/3.3 would be sufficient. > > That, updating the 2.7 and 3.2 docs with a reference to the fleshed > out 3.3 semantics and converting the assert() to a Python exception > should cover it.
One problem here: if the code raises an exception, it should properly clean up after itself. Meaning that it must call PyBuffer_Release() on the already acquired buffer - thus proving that the code actually works, except that it decides to raise an exception. I keep failing to see the interest in making this an error in the first place. Why would the object that bf_getbuffer() is being called on have to be identical with the one that exports the buffer? Stefan _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
