|> Pros
|> 1. Some errors spotted earlier in the development process.
|>
|> 2. Both #ifdef and #if forms will not warn if you mis-spell the
|> symbol, but #if has the advantage that _eventually_, a
|> mis-spelling warning is likely to be added to the compiler.
That's already available: -Wundef.
|> 3. The "always defined" form is more flexible, because you have
|> the option of using `#if X', `if (X)' or even using X in an
|> expression, e.g. `X ? a : b', `X && blah_blah'.
|>
|> Cons
|>
|> 1. Some things will optimise worse if you use `if' -- e.g., if
|> an `if (0)' branch takes the address of a variable, that will
|> still suppress some optimisations of that variable even when
|> the branch is optimised away. However, I'm don't think
|> that's all that common, and GCC can always be tweaked in the
|> long run if it is worth doing.
That should be fixed now that gcc has ADDRESSOF.
|> 2. Compilation might take longer because more code is compiled.
|> Then again, the fact that more code is compiled means more
|> errors are found.
|>
|> 3. There's a lot of existing code; if CONFIG_FOO were changed to
|> be defined always, the existing code would compile
|> differently without warning. (This is why C_FOO makes sense).
4. Strings in the if (0) branch are still emitted.
-- Andreas Schwab "And now for something schwab@issan.cs.uni-dortmund.de completely different" schwab@gnu.org- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/