| msg270806 - (view) |
Author: Martin Panter (martin.panter) *  |
Date: 2016-07-19 02:57 |
| This patch fixes errors reported by GCC’s undefined behaviour sanitizer about calling functions with a null pointer: ./configure CC="gcc -fsanitize=undefined" Using Issue 22605 as a precedent, I propose to avoid calling memcpy() and memmove() for zero-length copies when there may be a null pointer. |
|
|
| msg271135 - (view) |
Author: Martin Panter (martin.panter) * |
Date: 2016-07-24 07:25 |
| V2 patch adds another fix, uncovered by recent datetime tests: >>> a = array("B") >>> a[:] = a /media/disk/home/proj/python/cpython/Modules/arraymodule.c:748:5: runtime error: null pointer passed as argument 1, which is declared to never be null /media/disk/home/proj/python/cpython/Modules/arraymodule.c:748:5: runtime error: null pointer passed as argument 2, which is declared to never be null |
|
|
| msg271874 - (view) |
Author: Martin Panter (martin.panter) * |
Date: 2016-08-03 05:31 |
| Patch 3 fixes some more cases I found in the array module: >>> a + a Modules/arraymodule.c:809:5: runtime error: null pointer passed as argument 1, which is declared to never be null Modules/arraymodule.c:809:5: runtime error: null pointer passed as argument 2, which is declared to never be null Modules/arraymodule.c:810:5: runtime error: null pointer passed as argument 1, which is declared to never be null Modules/arraymodule.c:810:5: runtime error: null pointer passed as argument 2, which is declared to never be null array('B') >>> a * 3 Modules/arraymodule.c:840:9: runtime error: null pointer passed as argument 1, which is declared to never be null Modules/arraymodule.c:840:9: runtime error: null pointer passed as argument 2, which is declared to never be null array('B') >>> a += a Modules/arraymodule.c:952:5: runtime error: null pointer passed as argument 1, which is declared to never be null Modules/arraymodule.c:952:5: runtime error: null pointer passed as argument 2, which is declared to never be null I wondered if there is a good argument for fixing these, or if it is only a theoretical problem. Apparently GCC can do optimizations about null pointer tests: <https://gcc.gnu.org/gcc-4.9/porting_to.html>. I don’t think any of the cases I found are instances of this problem, but I think fixing them helps keep the UB sanitizer output clean, so any errors causing practical behaviour problems will be easier to find. |
|
|
| msg274701 - (view) |
Author: Martin Panter (martin.panter) * |
Date: 2016-09-07 02:15 |
| Looks like revisions 5f3f6f1fb73a and ec537f9f468f may have fixed the listobject cases. Also 66feda02f2a5 looks relevant. Benjamin, maybe you are interested in other bits of my patches :) |
|
|
| msg274708 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2016-09-07 02:29 |
| Sorry I missed this. The changes which I didn't already make look good. :) |
|
|
| msg274917 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2016-09-07 23:42 |
| New changeset e231dcad3a9b by Martin Panter in branch '3.5': Issue #27570: Avoid zero-length memcpy() calls with null source pointers https://hg.python.org/cpython/rev/e231dcad3a9b New changeset 2d0fb659372c by Martin Panter in branch 'default': Issue #27570: Merge null pointer fixes from 3.5 https://hg.python.org/cpython/rev/2d0fb659372c |
|
|
| msg274969 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2016-09-08 05:42 |
| New changeset d465da1e5902 by Martin Panter in branch '2.7': Issue #27570: Avoid zero-length memcpy() calls with null source pointers https://hg.python.org/cpython/rev/d465da1e5902 |
|
|