Date: Tue, 16 Jun 2020 20:39:36 -0600 From: Ian Lepore <ian@freebsd.org> To: rgrimes@freebsd.org, Cy Schubert <Cy.Schubert@cschubert.com> Cc: Toomas Soome <tsoome@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r362217 - head/stand/common Message-ID: <337eaa72d621d514583c776f70d4a3d1c4a7cf83.camel@freebsd.org> In-Reply-To: <202006161730.05GHUc9B082017@gndrsh.dnsmgr.net> References: <202006161730.05GHUc9B082017@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2020-06-16 at 10:30 -0700, Rodney W. Grimes wrote: > > In message < > > 55903c38d363aef2a6f6d0075dd4526b86d51258.camel@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?337eaa72d621d514583c776f70d4a3d1c4a7cf83.camel>