Py_DECREF() is missing do-while macro guards (as found
e.g. in Py_CLEAR), instead relying on being an if-else
to avoid the usual problems associated with such macros.

However if it is used as e.g. "if (newref)
Py_DECREF(obj);" then gcc -Wall still complains about
an ambiguous else clause.  (gcc version is 3.3.5)

Granted it is only a warning but like many people we
build with -Werror, and the code in question is in SWIG
output rather than our own code, so this is quite
painful for us.

At least Py_DECREF, Py_XDECREF and Py_XINCREF need
fixing; I've not checked beyond this.

Logged In: YES 
user_id=80475

Tim, what you think about doing this with a conditional
compile to only redefine for GCC?

Logged In: YES 
user_id=217390

Making it compiler-specific seems silly.  It's not like the
do-while idiom for macros is some strange gcc-specific
thing; most people just use it unconditionally on
complicated macros.

Logged In: YES 
user_id=31435

rjk1002:  it's idiotic complaints about unambigous (in reality) 
if/else structures that are unique to gcc.  Not all compilers 
optimize away the "do {...} while(0)" cruft in debug builds; 
the most important examples for Python are the Microsoft 
compilers.  Because the incref and decref macros are used a 
*lot*, it's unattractive to burden all platforms with this just 
to shut up one compiler.  I don't care about Py_CLEAR() 
(etc), because they're so lightly used.  The incref/decref 
macros are ubiquitous.

I would much rather see SWIG change to insert curlies.  That 
is, generating "if (newref) {Py_DECREF(obj);}" should be just 
as effective at shutting up this gcc nag.  Has anyone asked 
the SWIG project to do this?

Logged In: YES 
user_id=217390

It's unambiguous to the compiler.  The warning is there
because humans sometimes get it wrong.

Marginally reduced optimization in a debug build is hardly a
real problem.

Assigning to Matthias since he added do-while(0) to Py_DECREF in r71229.

committed these in r71229 and r71271. I'm not yet closing the report.

tim_one, I will conditionalize these, but I'm unsure if these should be
conditionalized on compilers which are known not to optimize, or if it
should be just conditionalized on gcc (and icc?).