Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Mar 2009 11:21:11 -0700
From:      Julian Elischer <julian@elischer.org>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, avg@FreeBSD.org, marius@alchemy.franken.de, svn-src-head@FreeBSD.org, christoph.mallon@gmx.de
Subject:   Re: svn commit: r190098 - in head/sys/sparc64: fhc sparc64
Message-ID:  <49C68197.1060204@elischer.org>
In-Reply-To: <20090322.070349.195750067.imp@bsdimp.com>
References:  <49C5737F.1050902@gmx.de>	<20090321.175756.-434257642.imp@bsdimp.com>	<49C5F88C.3070600@freebsd.org> <20090322.070349.195750067.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote:
> In message: <49C5F88C.3070600@freebsd.org>
>             Andriy Gapon <avg@freebsd.org> writes:
> : on 22/03/2009 01:57 M. Warner Losh said the following:
> : > I'll point out that style(9) doesn't say use as few local variables as
> : > possible...  That part is completely unspecified.
> : 
> : But it does say:
> : Do not put declarations inside blocks unless the routine is unusually
> : complicated.
> 
> Yea, so?  Just put them at the top of the function where they belong
> and don't worry about it.  Christoph has a long reason why this isn't bad.
> 
> : "unusually complicated" is, of course, a very subjective measure.
> : But still this guideline contradicts typical guidelines for C and its
> : offspring which name we do not say to declare variables as close to
> : their first usage as possible.
> 
> thousands of lines is unusually complicated.
> 
> : E.g. you can have a simple 3 line block where you need a local variable
> : but that block is located 50 lines from start of an enclosing function.
> : Very convenient when you need to quickly glance the variable's type (not).
> 
> No you don't.  There's absolutely nothing wrong with putting them at
> the top.  In fact, it is simpler, really, than having to go hunting
> for dozens of different declarations.  As someone who has spent a lot
> of time looking at code, the time wasted looking for these damn-fool
> things really adds up.

and in a complicated function, if you have them all over the place you 
have no idea as to what the potential stack usage of the function is..
This matters in the kernel.

> 
> The original point is valid: the code changes obfuscated perfectly
> readable code for no gain in the object code.
> 
> Warner




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