[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.024 / U:16.208 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site