WIP, MAINT: simplify generic type memory handling #11836
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was experimenting with various permutations of the memory handling used by the
generic
type arrays. There's a comment in the source suggesting that we may not necessarily need to zero allocated memory before initializing the type data into it.I figured this might be a bad idea since "residual" data in that memory block might cause all kinds of mysterious behaviors with things that are "supposed to be 0" actually being something else because of whatever was there before, etc.
However, I only see one unit test failure in the
--mode=full
test suite after making the change,test_pickle_empty_string
, which produces a bizarre failure whereb' '
!=b' '
; perhaps related to #5475. The test failure report is not informative at all -- it shows two identical-looking objects as being unequal, but maybe there's a subtle null-termination or related issue because of the non-zeroing.I can also get the full suite to pass if I switch to
PyObject_Calloc
to auto-zero the memory block and then we can just use(void) PyObject_InitVar((PyVarObject *)obj, type, nitems);
and not worry about fixed-width vs. variable width types because the tp_itemsize is used in a memory-related product downstream and should be 0 for fixed case. Although the full suite passes, I think the Python C API for that is 3.5 +.Edit: see Python 3.6 --full test suite job for single failure; Python 2.7 is another matter