This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Py_RETURN_NONE causes too much warnings
Type: Stage:
Components: Interpreter Core Versions: Python 2.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: tim.peters Nosy List: brett.cannon, rhettinger, thiagocorrea, tim.peters
Priority: normal Keywords:

Created on 2004-07-20 03:36 by thiagocorrea, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (13)
msg21702 - (view) Author: Correa (thiagocorrea) Date: 2004-07-20 03:36
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif
msg21703 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-07-20 11:27
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?
msg21704 - (view) Author: Correa (thiagocorrea) Date: 2004-07-20 15:27
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32

msg21705 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-07-21 00:40
Logged In: YES 
user_id=357491

You can't use inline; that is not supported in C89 but only C99 which we 
do not support.

As for why we can't just make the macro ``{Py_INCREF(Py_None); 
return Py_None;}``, I don't know.  K&R seems to suggest that the syntax 
is at least legal.
msg21706 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-07-21 01:26
Logged In: YES 
user_id=31435

"do {...} while(0)" is the standard C idiom for writing a multi-
statement macro; the reason "{...}" doesn't work is 
explained, e.g., here:

http://www.eskimo.com/~scs/C-faq/q10.4.html

thiagocorrea, we need more words from you.  Python is built 
every day using MSVC 6.0, and Visual Studio 7.1, with no 
warnings of any kind.  Indeed, "no warnings under MSVC" is a 
groundrule for the Python project.  Exactly how do you 
compile it?  Do you use the Visual Studio project files in the 
PCBuild subdirectory?

Brett is correct that we cannot use "inline" either.
msg21707 - (view) Author: Correa (thiagocorrea) Date: 2004-07-21 02:26
Logged In: YES 
user_id=111587

I'm not building Python.
I use python embedded on my project ( sf.net/projects/wpdev
) for scripting.

I often build using Level 4 warning (/W4) setting, usefull
for finding bugs. Also, it's built using C++ compiler not C.

Well, I don't know much about C standards but I do know a
lot about C++, and for C++ inline is just a hint to the
compiler, it might very well completely ignore it or ( it
usually does ) inline functions that were not marked as
"inline". If that's the problem, then drop the "inline"...
or have a macro to detect that inline is supported by the
compiler.
#ifdef __cplusplus
#define INLINE inline
#else
#define INLINE
#endif

Other checks could be added as well to enable it on C99
compliant compilers.
The point here is that the compiler is right complainning
about the constant conditional there.
I know that a simple {} block doesn't work well, but a
function call will, and the call itself will also be
optimized out by the compiler.
msg21708 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-07-21 03:05
Logged In: YES 
user_id=31435

There are at least 27 macros in core Python that use this 
standard C idiom, and you're the first person to raise an 
objection.  I recommend closing this as "Won't Fix" -- unless 
you have a much simpler suggestion than rewriting all these 
things.  More mounds of C preprocessor convolution would 
harm maintainability and readablity for everyone, and if that's 
the tradeoff, I'd rather you learn how to set an appropriate 
warning level when compiling Python sources.

BTW, Python uses /W3.  As the MS docs say, "[/W4] should 
be used only to provide 'lint' level warnings and is not 
recommended as your usual warning level setting".  We 
promise no warnings at /W3, but that's all.
msg21709 - (view) Author: Correa (thiagocorrea) Date: 2004-07-21 16:53
Logged In: YES 
user_id=111587

Again, I'm not compiling python sources, I'm using the
public C API.

The tradeoff isn't maintainability at all nor readability,
unless you want to imply that there is a python developer
who can't understand the concepts of function call/definition ;)
The question is how the above solution differ from the one
in the current source. And that's the warning level,
considering that it's the compiler job to optimize out the
function call.

There is nothing wrong in using /W4 once in a while, and
it's acctually a good idea.

I'm only asking to change 3 macros, not 27. Or at very
least, don't assume it has never been defined before, do a
#ifdef, so I can make my own improved version.

Perhaps I'm the first person concerned with a clean public API.
msg21710 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-07-21 18:37
Logged In: YES 
user_id=31435

Python is written to the C89 standard, and has to compile 
under a great many C compilers besides the one you use.  
There's no way we're going to accept preprocessor tricks that 
end up turning these macros into actual function calls under 
compilers that don't support "inline" (which isn't part of C89), 
so that idea was dead on arrival.

If you want to submit a patch to stuff #ifndef around the 
macro definitions you care about, and supply your own 
compiler-specific versions of those, that would be fine by me.
msg21711 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-07-21 18:46
Logged In: YES 
user_id=31435

One other idea for these:  Py_INCREF expands to (at worst) a 
comma-expression under all Python build types, so e.g.,

#define Py_RETURN_NONE \
    return Py_INCREF(Py_None), Py_None

should (untested) work.  Comma expressions don't create 
problems with if/else structures.
msg21712 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-07-21 19:23
Logged In: YES 
user_id=80475

Nick Bastin encountered this same issue with the SunPro C
compiler.  The solution was to add a compiler specific
pragma to pyport.h.  I recommend that you submit a similar
patch.  Assign it to me and I'll apply it for you.

Altering the macro itself is probably the wrong way to go. 
Python has no shortage of while statements with constant
conditions.  They are everywhere and IMO are a valid idiom.

msg21713 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-07-21 19:39
Logged In: YES 
user_id=31435

Which problem did Nick have?  Many of the "do {} while(0)" 
macros in Python are internal to C files, so aren't visible to 
people merely using the public API (as opposed to compiling 
Python itself).  The three thiagocorrea complains about are 
part of the public API.  I think it's easy to predict that he 
won't want to disable the "constant expression" message in 
pyport.h, because then it would be disabled too in all *his* 
code that merely includes Python.h in order to use the Python 
C API.

I certainly don't mind switching to a different C89 idiom where 
one is available.
msg21714 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-07-22 01:49
Logged In: YES 
user_id=31435

Rewrote Py_RETURN_{NONE, TRUE, FALSE} to expand to 
comma expressions:

Include/boolobject.h; new revision: 1.8
Include/object.h; new revision: 2.128
History
Date User Action Args
2022-04-11 14:56:05adminsetgithub: 40601
2004-07-20 03:36:51thiagocorreacreate