[Python-Dev] Py_DECREF causes spurious gcc warning (original) (raw)

Zack Weinberg zack at codesourcery.com
Sat Dec 20 16:17:50 EST 2003

"Tim Peters" <tim.one at comcast.net> writes:

[Zack Weinberg]

I thought you might come back at me with that. Yes, you can avoid the syntax error by carefully leaving off the semicolon here. I don't consider this to be good style, though. It's easy to forget, and it's easy for someone to come along later and be confused and check in an 'obvious' patch that adds a semicolon - and it might not even break anything... then. Zack, you have to be kidding. Martin was clearly talking about the expansion of PyDECREF specifically, not "macros in general", as also was the poster who started this thread.

I, however, was never speaking about Py_DECREF specifically. I thought this was clear from previous statements but I apologize for the confusion.

I'm speaking about general style principles, and I really do think it is good style always to wrap complex macros in do { } while (0) whether or not they need it. PyDECREF doesn't need it; there may be some point to it if doing so shuts up gcc nuisance complaints, and we can be sure that the extra complexity of the expanded code doesn't provoke optimization bugs in any of the C compilers used to compile Python. Writing non-loops as loops is a good way to tickle endcase bugs in sophisticated optimizers -- it's not without risk, and there are several thousand instances of PyDECREF and PyXDECREF just in the core. Also because it's used a lot, in a debug build such a change would generate a ton of useless extra instructions (at least MSVC really does generate code to create a zero, test it against zero, and jump back to the top of "the loop" if zero doesn't equal zero; I expect that most C compilers would).

I doubt both statements just because this is a standard C idiom. Recognizing it and generating no extra code falls naturally out of basic constant-condition detection, which I would expect to be present in any modern compiler, - and done even in "debug builds" because it can't hurt and in fact usually makes the compiler run faster (less junk intermediat code to process). I especially doubt that this construct will tickle bugs in sophisticated optimizers -- it would be harder to get it wrong than to get it right.

I am not disputing that MSVC does this silly thing you describe, but MSVC has a long track record of bugs and poor code generation. GCC does not generate junk code even at -O0.

zw

More information about the Python-Dev mailing list