[issue30459] PyList_SET_ITEM could be safer
Espie Marc added the comment: On Sat, Dec 05, 2020 at 01:28:33AM +, STINNER Victor wrote: > > STINNER Victor added the comment: > > I propose to merge my PR 23645 change right now. If it breaks too many C > extensions, we still have time before Python 3.10.0 final scheduled at > Monday, 2021-10-04, to revert the change. > > > "if (obj == NULL || PyList_SET_ITEM (l, i, obj) < 0)" > > Well, this is obviously a bug in py-qt4 and it's a good thing to get a > compiler error on such code. I guess that the intent was to use > PyList_SetItem(). > > It's also an issue for Python implementation other than CPython which does > not behave exactly like CPython C API. I prefer to fix the C API to make it > respect its own documentation (return "void"). > > > Espie Marc: "Well, there is not going to be a lot of breakage. This problem > is the only instance I've encountered in the full OpenBSD ports tree." > > Oh, thanks for providing this very useful feedback! That's very promising. > > Did you report the issue to py-qt4 upstream? If yes, can you please copy here > the link to your report? I'm sorry, it's been so long ago, I can't remember. I've been dealing with 10s of other bugs since. -- ___ Python tracker <https://bugs.python.org/issue30459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30459] PyList_SET_ITEM could be safer
New submission from Espie Marc:
Documentation says PyList_SET_ITEM is void, but it lies. The macro is such that
it yields the actual element being set.
wrapping the macro content in a do {} while (0) makes sure PyList_SET_ITEM is
really void, e.g.:
#define PyList_SET_ITEM(op, i, v) do { (((PyListObject *)(op))->ob_item[i] =
(v)); } while (0)
I just ran into the problem while compiling py-qt4 with clang.
There was some confusion between PyList_SET_ITEM and PyList_SetItem:
if (obj == NULL || PyList_SET_ITEM (l, i, obj) < 0)
g++ didn't catch it (because it doesn't see negative pointers as a problem),
but clang++ instantly broke.
With PyList_SET_ITEM truly void the problem disappears.
--
components: Interpreter Core
messages: 294362
nosy: espie
priority: normal
severity: normal
status: open
title: PyList_SET_ITEM could be safer
type: enhancement
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue30459>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30459] PyList_SET_ITEM could be safer
Espie Marc added the comment: Well, there is not going to be a lot of breakage. This problem is the only instance I've encountered in the full OpenBSD ports tree. I thought python was supposed to be a clean language, and didn't shy away from removing stuff/tweaking stuff to achieve that goal ?... The py-kde4 error was deadly. I'm lucky clang finally caught it, but I'd rather this kind of stuff just not compile. I think we're in a world where *correctness* is finally beginning to matter a bit more than *compatibility forever whatever the cost*. -- ___ Python tracker <http://bugs.python.org/issue30459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30459] PyList_SET_ITEM could be safer
Espie Marc added the comment: yep, casting to (void) would be safer indeed. didn't think of that one ;) -- ___ Python tracker <http://bugs.python.org/issue30459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30459] PyList_SET_ITEM could be safer
Espie Marc added the comment: Note that the API is fully documented for returning void... not anything else. "No basis" right. We're taling 1 pieces of software. a lot of what is actually used in the world. I'm very surprised, considering python has routinely done "spring cleanup" by breaking fairly old apis. If this breaks, people will fix their code, seriously. In most places, we would rather have undocumented, unportable code, break *cleanly*, rather than rely on a fuzzy behavior that could possibly change at any moment, and that was never documented as doing anything. Or is there some kind of mystique that, because this is low-level C implementation, somehow, python programmers are not going to be able to cope with the internals ? -- ___ Python tracker <http://bugs.python.org/issue30459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30459] PyList_SET_ITEM could be safer
Espie Marc added the comment: it's still 100% safe as a macro since each parameter is not used more than once. only the return type is an issue. -- ___ Python tracker <http://bugs.python.org/issue30459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
