Date: Fri, 01 May 2009 13:37:23 +0200 From: Christoph Mallon <christoph.mallon@gmx.de> To: Marius Strobl <marius@alchemy.franken.de> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Roman Divacky <rdivacky@freebsd.org>, Ed Schouten <ed@freebsd.org>, Warner Losh <imp@freebsd.org>, Maxim Sobolev <sobomax@freebsd.org> Subject: Re: C99: Suggestions for style(9) Message-ID: <49FADEF3.5010106@gmx.de> In-Reply-To: <20090501112239.GA23199@alchemy.franken.de> References: <49F4070C.2000108@gmx.de> <20090501112239.GA23199@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
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).
Christoph
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49FADEF3.5010106>