Date: Sat, 02 May 2009 20:18:58 +0200 From: Christoph Mallon <christoph.mallon@gmx.de> To: Julian Elischer <julian@elischer.org> Cc: Maxim Sobolev <sobomax@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Roman Divacky <rdivacky@freebsd.org>, Ed Schouten <ed@freebsd.org>, David Malone <dwmalone@maths.tcd.ie>, Warner Losh <imp@freebsd.org> Subject: Re: C99: Suggestions for style(9) Message-ID: <49FC8E92.1090207@gmx.de> In-Reply-To: <49FC8920.6050408@elischer.org> References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> <49FC8574.5060205@gmx.de> <49FC8920.6050408@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer schrieb:
> Christoph Mallon wrote:
>> variables. Sorting them in a beneficial way for space efficiency is
>> better left to them (and it is a rather trivial thing to do). Also you
>> cannot control if more spill slots have to be inserted or some values
>> do not live in memory at all, so only the compiler can determine,
>> which order is best.
>> But a compiler can do more: It could coalesce the space of variables
>> with disjoint life ranges. But this is much harder, because you have
>> to properly determine the life ranges. Finding an arbitrary
>> overestimation is easy, but the fun starts when looking at called
>> functions, which get passed addresses of local variables. Also finding
>> an optimal coalescence for known life ranges is NP-complete in the
>> general case. But that's another story. (:
>
> re-using space or having block-local variables means that when you
> are in the debugger, you can not look at the final value that
> a variable had when you left (unexpectedly) the block. This can
> be a pain in the neck. (but only a debugging feature)
I'm talking about an optimized build - no matter what the style of the
original source was, you will have a hard time debugging it.
>>>>>> +Prefer initializing variables right at their declaration.
>>>>
>>>
>>> I have gone the other way on this. Unless 'const' is being used I
>>> find I prefer to see them separately initialized.
>>
>> So you like hunting in multiple places instead of having both type and
>> value conveniently in one place?
>
> Actually.. yes
So at the one hand you argue that hunting things is bad, but at the same
time you prefer it? I am confused.
> unconditional initialization is right at the top, AFTER the blank line.
> Conditional initialization must of course come after the condition, and
> can not be in the same line as the declaration anyhow.
It is perfectly valid to do so. Warner presented a simple example. You
just have to limit the scope of the variable, which is a good for other
reasons, which were explained, too.
>>>>>> +Do not reuse the same variable in a different context, delare a
>>>>>> new variable.
>>>>
>>>> I buy this largely - though it should be applied with common sense
>>>> as usual.
>>>
>>> hmm. I think an exception might be made for our old friends i,j,k
>>
>> Especially they should be declared right where they are needed. C99
>> even conveniently allows the iterator variable to be declared in the
>> first part of a for-loop: for (int i = 0; i != n; ++i) { ... }. By
>> limiting their scope, this prevents accidently re-using stale values
>> in a different place or other mistakes like the following:
>> int i, j;
>> for (i = 0;; ++i) {
>> for (i = 0;; ++i) {
>> /* oops, but compiler is happy */
>> }
>> }
>> for (j = 0;; ++j) {
>> /* more */
>> }
>> vs.
>> for (int i = 0;; ++i) {
>> for (int i = 0;; ++i) {
>> /* warning about shadowed variable */
>> }
>> }
>> for (int j = 0;; ++j) {
>> /* more */
>> }
>
> while tempting, I can't see that hapenning..
>
> it stops teh following:
>
>
> for (;;) {
> blah
> if (foo)
> break;
> }
> if (i == end_condition) {
> then we didn't break out;
> }
You reject a common case because of one special case? This is sad. (Also
there are multiple ways to resolve this nicely, e.g. split the loop into
a function or invert the condition and restructure the code slightly)
>>>>>> -Use ANSI function declarations unless you explicitly need K&R
>>>>>> compatibility.
>>>>>> +Use ANSI function declarations.
>>>>
>>>
>>> Everyone shuld be doing that already.
>>> In new code, and in old code that they touch.
>>
>> So, is this pro or contra removing the K&R-clause?
>
> K&R code should be changed as part of related changes if possible.
> A sweep to change a whole file is probably also ok.
> changing them one at a time is probably not ok.
But this is what actually is practiced.
You still did not answer my question: Do you agree to remove the clause
so no new old style declarations may be added?
Christoph
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49FC8E92.1090207>