[issue28855] Compiler warnings in _PyObject_CallArg1()

2016-12-02 Thread STINNER Victor
STINNER Victor added the comment: No problem, thanks for the fix Benjamin! -- ___ Python tracker ___ ___

[issue28855] Compiler warnings in _PyObject_CallArg1()

2016-12-01 Thread Benjamin Peterson
Benjamin Peterson added the comment: I also think forcing callers to cast is fine. Most of our APIs require PyObject *. -- ___ Python tracker ___

[issue28855] Compiler warnings in _PyObject_CallArg1()

2016-12-01 Thread Benjamin Peterson
Benjamin Peterson added the comment: (Sorry, I noticed and landed a fix before completely reading the issue.) -- ___ Python tracker ___

[issue28855] Compiler warnings in _PyObject_CallArg1()

2016-12-01 Thread Benjamin Peterson
Benjamin Peterson added the comment: It doesn't seem like the question is whether to use inline functions but whether to force all callers to cast. Your original code would work if you added all the casts in your static_inline.patch patch. -- ___

[issue28855] Compiler warnings in _PyObject_CallArg1()

2016-12-01 Thread Roundup Robot
Roundup Robot added the comment: New changeset 96245d4af0ca by Benjamin Peterson in branch 'default': fix _PyObject_CallArg1 compiler warnings (closes #28855) https://hg.python.org/cpython/rev/96245d4af0ca -- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open ->

[issue28855] Compiler warnings in _PyObject_CallArg1()

2016-12-01 Thread STINNER Victor
New submission from STINNER Victor: _PyObject_CallArg1() is the following macro: --- #define _PyObject_CallArg1(func, arg) \ _PyObject_FastCall((func), &(arg), 1) --- It works well in most cases, but my change 8f258245c391 or change b9c9691c72c5 added compiler warnings, because an argument