Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.200,2.201
On Thu, Aug 31, 2000 at 05:02:01PM -0700, Tim Peters wrote:
Update of /cvsroot/python/python/dist/src/Python In directory slayer.i.sourceforge.net:/tmp/cvs-serv20859/python/dist/src/Python
Modified Files: ceval.c Log Message: Supply missing prototypes for new Py_{Get,Set}RecursionLimit; fixes compiler wngs; un-analize Get's definition ("void" is needed only in declarations, not defns, & is generally considered bad style in the latter).
wtf? Placing a void in both declaration *and* definition is "good style". static int foo(void) { ... } int bar() { ... } You're setting yourself up for inconsistency if you don't always use a prototypical definition. In the above example, foo() must be declared/defined using a prototype (or you get warnings from gcc when you compile with -Wmissing-prototypes (which is recommended for developers)). But you're saying bar() should *not* have a prototype. -1 on dropping the "void" from the definition. I disagree it is bad form, and it sets us up for inconsistencies. Cheers, -g -- Greg Stein, http://www.lyra.org/
[Greg Stein]
... static int foo(void) { ... } int bar() { ... }
You're setting yourself up for inconsistency if you don't always use a prototypical definition. In the above example, foo() must be declared/defined using a prototype (or you get warnings from gcc when you compile with -Wmissing-prototypes (which is recommended for developers)). But you're saying bar() should *not* have a prototype.
This must be about the pragmatics of gcc, as the C std doesn't say any of that stuff -- to the contrary, in a *definition* (as opposed to a declaration), bar() and bar(void) are identical in meaning (as far as the std goes). But I confess I don't use gcc at the moment, and have mostly used C grudgingly the past 5 years when porting things to C++, and my "bad style" really came from the latter (C++ doesn't cater to K&R-style decls or "Miranda prototypes" at all, so "thing(void)" is just an eyesore there).
-1 on dropping the "void" from the definition. I disagree it is bad form, and it sets us up for inconsistencies.
Good enough for me -- I'll change it back.
You're setting yourself up for inconsistency if you don't always use a prototypical definition. In the above example, foo() must be declared/defined using a prototype (or you get warnings from gcc when you compile with -Wmissing-prototypes (which is recommended for developers)). But you're saying bar() should *not* have a prototype.
-1 on dropping the "void" from the definition. I disagree it is bad form, and it sets us up for inconsistencies.
We discussed this briefly today in our group chat, and I'm +0 or Greg's recommendation (that's +0 on keeping (void) in definitions). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
participants (3)
-
Greg Stein -
Guido van Rossum -
Tim Peters