From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 08 Apr 2009 15:52:26 -0500 Subject: [U-Boot] use of C99 In-Reply-To: References: <4A0B9AAA-4714-4C27-84A7-22FCE4D91DDA@freescale.com> <20090408192832.8D48F8560EFB@gemini.denx.de> <49DCFF1D.6080006@ge.com> Message-ID: <49DD0E8A.904@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Timur Tabi wrote: > On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren wrote: > >> ACK. I don't expect to see variables spring into life in the middle of >> nowhere. > > I don't see what's wrong with that. The advantage is that the > variable is close to where it's being used, so that you can see the > context more easily. Agreed. In many cases it reduces clutter by eliminating the need for separate declaration and assignment. > I don't see what the value is of limiting the lifetime of the > variable. It frees the variable up for later such blocks to use. As does declaring iterators inside a for loop, but I guess that's forbidden as well. :-) > It's just going to use this for syntax checking. If you define and > initialize a variable at the top of the function, but don't use that > variable until a hundred lines later, the compiler is going to > initialize the variable when it's first used, not when the function is > first entered. Chances are it's not even going to define stack space > for it. Chances are it will allocate all stack space for all variables up front, regardless of where they're declared. >> #ifdef CONFIG_COOL_FEATURE >> { >> u32 myvarrocks = foo * bar * bar; >> >> gd->neato = myvarrocks >> } >> #endif >> >> Is this an acceptable compromise? > > This is what we do today, and I think it's ugly. Yes. But not as ugly as having two #ifdef blocks. -Scott