Date: Fri, 01 May 2009 08:20:20 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: christoph.mallon@gmx.de Cc: sobomax@freebsd.org, freebsd-hackers@freebsd.org, rdivacky@freebsd.org, ed@freebsd.org, marius@alchemy.franken.de Subject: Re: C99: Suggestions for style(9) Message-ID: <20090501.082020.698246310.imp@bsdimp.com> In-Reply-To: <49FADEF3.5010106@gmx.de> References: <49F4070C.2000108@gmx.de> <20090501112239.GA23199@alchemy.franken.de> <49FADEF3.5010106@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <49FADEF3.5010106@gmx.de>
Christoph Mallon <christoph.mallon@gmx.de> writes:
: Marius Strobl schrieb:
: > On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
: >> return with parentheses:
: >> Removed, because it does not improve maintainability in any way. There
: >> is no source for confusion here, so the rule even contradicts the rule,
: >> which states not to use redundant parentheses. Maybe, decades ago it was
: >> just a workaround for a broken compiler, which does not exist anymore.
: >
: > FYI, the idea behind this rule is said to be to able to use
: > a macro return(), f.e. for debugging you then can do:
: > #define return(x) do { \
: > printf("returning from %s with %d\n", __func__, (x)); \
: > return (x); \
: > } while (0)
: >
: > Given the this is a nifty feature and parentheses around the
: > return value don't hurt maintainability in any way IMO this
: > rule should stay.
:
: This is mentioned nowhere in style(9) (in general it is lacking reasons
: why something is some way or the other).
It has been an example used for the past 15 years at least as to why
to do this... I don't know how many people have actually used the
ability to do this in code.
: Also I consider this as gross abuse: Macro names shall be in all
: uppercase, so it is clear that there is a macro at work. Therefore
: "return" is not a candidate. So this would violate yet another rule in
: style(9) (the original return already violates the no-redundant
: parentheses rule).
: Also I would not mention __func__: there were objections against using
: it in the past (though I, logically, prefer its use).
It is a debugging aid, but one of dubious value for a far more
fundamental reason:
return;
will break any macro.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090501.082020.698246310.imp>