svn commit: r362217 - head/stand/common

[Ian Lepore]

On Tue, 2020-06-16 at 10:30 -0700, Rodney W. Grimes wrote:
> > In message <
> > 55903c38d363aef2a6f6d0075dd4526b86d51258.camel at freebsd.org>, 
> > Ian Le
> > pore writes:
> > > On Tue, 2020-06-16 at 07:05 +0000, Toomas Soome wrote:
> > > > Author: tsoome
> > > > Date: Tue Jun 16 07:05:03 2020
> > > > New Revision: 362217
> > > > URL: https://svnweb.freebsd.org/changeset/base/362217
> > > > 
> > > > Log:
> > > >   loader: variable i is unused without MBR/GPT support built in
> > > >   
> > > >   Because i is only used as index in for loop, declare it in
> > > > for
> > > > statement.
> > > > 
> > > 
> > > As much as I prefer doing it this way, style(9) doesn't allow for
> > > variable declarations inside a for() statement (or even inside a
> > > local
> > > block, which is just too 1980s for me, but it is still our
> > > standard).
> 
> Last time I tried to assert that bit of style(9) with respect to
> inside a local block I was over ridden, so it is probably time
> to atleast revisit that part of style(9).
> 
> > Doesn't this use stack for a shorter period of time or does the
> > compiler 
> > optimize this, making this change moot?
> > 
> > The tradeoff is a few extra bytes of stack for a longer period of
> > time vs a 
> > few extra instructions incrementing and decrementing the stack
> > pointer.
> 
> I do not think the reasoning had to do with stack space vs
> instuctions,
> but more about being able to clearly know about variable reuse and
> not
> do it as that can create fun bugs.
> 
> Tools have modernized since that part of style was written.

I think a modern compiler will likely emit one of those "declaration of
foo here shadows declaration in outer scope" type messages.  Not that
it should; IMO, part of the point of keeping definitions confined to as
local a scope as possible is to help ensure you're using the variable
you think you are in that local scope and not accidentally perturbing
something used elsewhere.

-- Ian