[issue15106] Potential Bug in errors.c

Change by Pablo Galindo Salgado : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___

[issue15106] Potential Bug in errors.c

Pablo Galindo Salgado added the comment: Adding extra checks to PyErr_SetExcInfo doesn't have a lot of value because is already out of of contract. If you pass an invalid object (let's say a list) to any of the specific APIs (like PyDict_GetItem) it will crash anyway. We could add some

[issue15106] Potential Bug in errors.c

Irit Katriel added the comment: The code is not really cloned - note that PyErr_Restore is operating on tstate->curexc (the exception currently being handled) while PyErr_SetExcInfo is operating on tstate->exc_info (the earliest exception currently on the exception stack). If there is a

[issue15106] Potential Bug in errors.c

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15106] Potential Bug in errors.c

Mark Lawrence added the comment: From what I can see the code is completely the same in default but does this matter or not? As a matter of interest is there an official policy regarding code clones, whether in C or pure Python? -- nosy: +BreamoreBoy

[issue15106] Potential Bug in errors.c

Changes by Ezio Melotti ezio.melo...@gmail.com: -- components: +Interpreter Core -None nosy: +ezio.melotti, serhiy.storchaka versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15106

[issue15106] Potential Bug in errors.c

New submission from Ken Cheung msrbugzi...@gmail.com: I observed a code clone from the following files. function : PyErr_Restore @ (file: Python-3.3.0a4/Python/errors.c, line: 27)~49 function : PyErr_SetExcInfo @ (file: Python-3.3.0a4/Python/errors.c, line: 341)~353 The function PyErr_Restore