[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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 which is not directly a PyObject* 
type is passed as "arg".

I tried to cast in the caller: _PyObject_CallArg1(func, (PyObject*)arg), but 
sadly it doesn't work :-( I get a compiler error.

Another option is to cast after "&" in the macro:
---
 #define _PyObject_CallArg1(func, arg) \
-_PyObject_FastCall((func), &(arg), 1)
+_PyObject_FastCall((func), (PyObject **)&(arg), 1)
---

This option may hide real bugs, so I dislike it.

A better option is to stop using ugly C macros and use a modern static inline 
function: see attached static_inline.patch. This patch casts to PyObject* 
before calling _PyObject_CallArg1() to fix warnings.

The question is if compilers are able to emit efficient code for static inline 
functions using "&" on an argument. I wrote the macro to implement the "&" 
optimization: convert a PyObject* to a stack of arguments: C array of PyObject* 
objects.

--
files: static_inline.patch
keywords: patch
messages: 282212
nosy: benjamin.peterson, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Compiler warnings in _PyObject_CallArg1()
versions: Python 3.7
Added file: http://bugs.python.org/file45729/static_inline.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com