lkml.org 
[lkml]   [1999]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: useful exercise
From
Date
Jamie Lokier <lkd@tantalophile.demon.co.uk> writes:

|> 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [from the cache]
©2003-2011 Jasper Spaans