> I confess I made no effort to verify that the > invariants actually hold. My view was that the invariants were so > mild and so necessary that any violation discovered should (and would) > be treated as a bug. > > > E.g. it is unclear to me why we allow list_ass_slice() to reset ob_item > to NULL > > and ob_size to 0 without resetting ob_allocated to 0 > > Since that violates one of the now-documented invariants, you can > guess my position on that. > > > -- I see why it doesn't crash in a subsequent list_resize(), but it > looks messy. list_resize() doesn't assume a valid value for ob_allocated unless ob_item != NULL. The idea was to avoid imposing new invariants on the list structure so that the remaining code and extensions would be easier to maintain. Ideally, no code outside of PyList_New() and list_resize() would need to know about the ob_allocated field. If we want to insist on the ob_allocated invariants, then * list_ass_slice() should add a line to maintain them, * list_resize() can drop the test for ob_item != NULL, and * tp_new needs a custom list_new() establishing the invariants. > > Alternatively, the quickest fix for the broken listsort() would have > been to > > keep the empty_ob_item hack but just check that ob_allocated is still > zero in > > addition to ob_size. > > Too ugly; I don't think either of us *liked* the empty_ob_item hack, > and if I was going to piss away more time on this I was determined to > get rid of it <wink>. That would be nice. list_sort() serves as the model for how to defend C code against list mutation. Raymond
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