On Tue, 2020-06-16 at 10:30 -0700, Rodney W. Grimes wrote: > > In message < > > 55903c38d363aef2a6f6d0075dd4526b86d51258.ca...@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
