<p dir="ltr"><br>
On 17 Feb 2014 06:12, "Serhiy Storchaka" <<a href="mailto:storchaka@gmail.com">storchaka@gmail.com</a>> wrote:<br>
><br>
> 16.02.14 02:05, Nick Coghlan написав(ла):<br>
><br>
>> It's also likely than many of these crashes could only be reproduced<br>
>> through incorrect usage of the C API.<br>
><br>
><br>
> Rather through queer or malicious usage of Python classes with strange code in __del__.</p>
<p dir="ltr">This change doesn't fix any of the known crashers in Lib/test/crashers, though - I applied the patch locally and checked.</p>
<p dir="ltr">>> For example:<br>
>><br>
>>      Py_CLEAR_AND_SET<br>
>>      Py_XCLEAR_AND_SET<br>
>><br>
>> Such that Py_CLEAR and Py_XCLEAR are equivalent to:<br>
><br>
><br>
> There is no Py_XCLEAR. Py_CLEAR itself checks its argument for NULL (as Py_XDECREF and Py_XINCREF). And these names looks too cumbersome to me.<br>
><br>
><br>
>> While the name does suggest the macro will expand to:<br>
>><br>
>>      Py_CLEAR(target);<br>
>>      target = value;<br>
>><br>
>> which isn't quite accurate, it's close enough that people should still<br>
>> be able to understand what the operation does.<br>
><br>
><br>
> This is not just inaccurate, this is wrong. Py_REPLACE first assigns new value and then DECREF old value.</p>
<p dir="ltr">The point is that people already know what Py_CLEAR does. This operation is like Py_CLEAR (the old reference is only removed *after* the pointer has been updated), except that the value it is being replaced with can be something other than NULL. If the replacement value *is* NULL, then the new operation is *exactly* equivalent to Py_CLEAR.</p>

<p dir="ltr">Operations that do related things should ideally have related names. The point of my deliberately erroneous expansion is that it's an error a reader can make while still correctly understanding the *logic* of the code, even though they're missing a subtlety of the mechanics.</p>

<p dir="ltr">> So it rather can be named as Py_SET_AND_DECREF, but of course this name looks ugly and confusing.</p>
<p dir="ltr">An explicit name like Py_SET_AND_DECREF would also be reasonable. It's substantially less confusing than Py_REPLACE, as it is less ambiguous about whether or not the refcount on the new value is adjusted.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a></p>