On Wednesday 07 January 2009, Ilpo J?rvinen wrote: > On Wed, 7 Jan 2009, Inaky Perez-Gonzalez wrote: > > On Wednesday 07 January 2009, Ilpo J?rvinen wrote: > > > On Tue, 6 Jan 2009, Inaky Perez-Gonzalez wrote: > > > > Reported by Randy Dunlap: > > > > > Also, this warning needs to be fixed: > > > > > > > > > > linux-next-20090106/net/wimax/id-table.c:133: warning: ISO C90 > > > > > forbids mixed declarations and code > > > > > > > > Move the return on #defined(CONFIG_BUG) below the variable > > > > declarations so it doesn't violate ISO C90. > > > > > > > > On wimax_id_table_release() we want to do a debug check if CONFIG_BUG > > > > is enabled. However, we also want the debug code to be always > > > > compiled to ensure there is no bitrot. > > > > > > I hope this kind of solution won't add some warnings? Besides, this > > > seems rather strange reasoning as CONFIG_BUG is mostly enabled anyway? > > > > Well, it is legal code -- short of 'if (1) return'. It doesn't warn (and > > it should not). > > Obviously, but I was concerned on the other lines than that > particular one, e.g., gcc might think that wimax_dev is unused > variable and emit a warning or along those lines...? Ah, I see -- no, it won't. [disclaimer: not know much about compiler optimization] In theory, as we were saying, it works just as in a case where you have int somevar; if (1) return; somevar = call_some_func(); with 1 being the result of a compile time evaluation. The compiler sees that somevar is being used, but the code path is never executed, so everything gets dumped. If it ever did, it'd be a matter of changing that return to an if (1) return. It'd look uglier though. -- Inaky
