Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 01 May 2009 22:55:39 +0200
From:      Christoph Mallon <christoph.mallon@gmx.de>
To:        Marius Strobl <marius@alchemy.franken.de>
Cc:        Maxim Sobolev <sobomax@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Roman Divacky <rdivacky@freebsd.org>, Ed Schouten <ed@freebsd.org>, Warner Losh <imp@freebsd.org>
Subject:   Re: C99: Suggestions for style(9)
Message-ID:  <49FB61CB.80906@gmx.de>
In-Reply-To: <20090501121018.GC2943@alchemy.franken.de>
References:  <49F4070C.2000108@gmx.de>	<20090501112239.GA23199@alchemy.franken.de>	<49FADEF3.5010106@gmx.de> <20090501121018.GC2943@alchemy.franken.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Marius Strobl schrieb:
> On Fri, May 01, 2009 at 01:37:23PM +0200, Christoph Mallon wrote:
>> 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).
> 
> I agree that style(9) lacks explanations, however this doesn't
> necessarily mean that non-obvious rules are "silly" and should
> be removed.

I neither said not implied this. I said, that it is lacking in 
justification, which clearly is bad.

>> 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).
> 
> In general this is correct, a return() macro (in which case
> the parentheses are not redundant) would be for local debugging
> only and not ever hit the tree just like any other printf()-
> debugging should not, so neither is relevant here. Besides,
> a macro without side effects, which a return() macro typically
> shouldn't have, is fine to be named all lowercase according
> to style(9).

So everybody has to pay with a small amount of obfuscation per return 
for an obscure trick, which compared to the number of returns is never used.
Therefore I don't consider the return-macro convincing at all.

	Christoph



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49FB61CB.80906>