[lkml]   [1999]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: useful exercise
Jamie Lokier <> 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 completely different"

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:49    [W:0.058 / U:2.780 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site