[ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings

Thu Jul 22 03:49:20 CEST 2004

Bugs item #994255, was opened at 2004-07-19 23:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Correa (thiagocorrea)
>Assigned to: Tim Peters (tim_one)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
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

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-21 21:49

Message:
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

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 15:39

Message:
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.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-21 15:23

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 14:46

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 14:37

Message:
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.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-21 12:53

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 23:05

Message:
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.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 22:26

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 21:26

Message:
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.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 20:40

Message:
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.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 11:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 07:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470