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: Please add do-while guard to Py_DECREF etc.
Type: enhancement Stage:
Components: Interpreter Core Versions: Python 3.1, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: doko Nosy List: BreamoreBoy, doko, georg.brandl, rhettinger, rjk1002, tim.peters
Priority: low Keywords:

Created on 2005-01-31 16:01 by rjk1002, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (8)
msg24112 - (view) Author: Richard Kettlewell (rjk1002) Date: 2005-01-31 16:01
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.
msg24113 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2005-02-01 02:53
Logged In: YES 
user_id=80475

Tim, what you think about doing this with a conditional
compile to only redefine for GCC?
msg24114 - (view) Author: Richard Kettlewell (rjk1002) Date: 2005-02-01 09:51
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.
msg24115 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2005-02-02 02:03
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?
msg24116 - (view) Author: Richard Kettlewell (rjk1002) Date: 2005-02-02 12:28
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.
msg85539 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-04-05 17:51
Assigning to Matthias since he added do-while(0) to Py_DECREF in r71229.
msg85566 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2009-04-05 21:22
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?).
msg114404 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-08-19 19:04
Can this be closed now, do the committs need porting to other versions or what?
History
Date User Action Args
2022-04-11 14:56:09adminsetgithub: 41508
2010-08-19 19:07:43benjamin.petersonsetstatus: open -> closed
resolution: fixed
2010-08-19 19:04:58BreamoreBoysetnosy: + BreamoreBoy
messages: + msg114404
2009-04-05 21:22:35dokosetmessages: + msg85566
2009-04-05 17:51:06georg.brandlsetassignee: doko

messages: + msg85539
nosy: + georg.brandl, doko
2009-02-15 22:33:46ajaksu2setpriority: normal -> low
type: enhancement
versions: + Python 3.1, Python 2.7, - Python 2.4
2005-01-31 16:01:10rjk1002create