GCC_WARN_SHADOW is essentially drawing your attention to you possibly doing something other than you intended. This is like most warnings, but the difference is that the behaviour GCC_WARN_SHADOW is blocking is very useful.

This is the sort of things the more paranoid compiler warnings are good at. The downside is that it’s difficult (not impossible) to drop a particular warning to indicate that you know what you’re doing.

With GCC_WARN_SHADOW on, this code will generate a warning:

int a = 5;
int b = 3;
int c = 4;
int value = MAX(a,MAX(b,c));

Despite that, it will function perfectly. The reason for the warning is that it compiles down to this:

({
   int __a = (a);
   int __b = (({
       int __a = (b);
       int __b = (c);
       __a < __b ? __b : __a;
   }));
   __a < __b ? __b : __a;
})

This is horribly ugly code. You wouldn’t want to write this code. You wouldn’t want to read it. But here’s the catch: it’s perfectly valid to the compiler, and hiding the ugliness is why MAX() exists.

There’s a few ways to avoid this. The first is to not use the MAX() macro at all:

int a = 5;
int b = 3;
int c = 4;
int value = a < b ? (b < c ? c : b) : a;

Or, you could do this:

int a = 5;
int b = 3;
int c = 4;
int temp = MAX(b,c);
int value = MAX(a,temp);

If you’re interested in temp — if it’s a value that has meaning — this is a fine approach. Give it a better name than temp and run with it. But if it’s a value that has no meaning other than an uninteresting temporary variable on your way to value, you’ve made your code worse.

Next up, you could turn off the warning:

int a = 5;
int b = 3;
int c = 4;
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wshadow"
int value = MAX(a,MAX(b,c));
#pragma GCC diagnostic pop

This last method can be simplified (a little):

#define PUSH_NOSHADOW _Pragma("GCC diagnostic push") _Pragma("GCC diagnostic ignored "-Wshadow"")
#define POP_NOSHADOW _Pragma("GCC diagnostic pop")
int a = 5;
int b = 3;
int c = 4;
PUSH_NOSHADOW
int value = MAX(a,MAX(b,c));
POP_NOSHADOW

This last technique suggests permanent fix: Apple could change the definition of MAX to avoid this (10296999).

But really? Just stop using GCC_WARN_SHADOW. It’s an unnecessary pain in the ass.

These are artificial examples, granted. But let’s pull this back to Objective-C, and something a typical Cocoa or Cocoa Touch programmer might have to do:

Also, if you use this you’ll need to name error variables in blocks differently:

NSError *e;
[self somethingWithError: &e];
[self runWithCompletion:^{
    NSError *e;
    [self recoverFromError:&e]; // warning, or rename inner error to e2
}];

Overall, I didn’t think it was worth the extra effort anymore. Your mileage will (of course) vary.

Rather than set these per project, I have a .xcconfig file I add to my project. I then base each build configuration off this file. Changing the .xcconfig file changes all projects based on it (though with the current Xcode, it’s sometimes necessary to reload the project to get the settings to take).

// // MoreWarnings.xcconfig // // Created by Steven Fisher: // http://tewha.net/2010/11/xcode-warnings/ // See also: // http://boredzo.org/blog/archives/2009-11-07/warnings //

GCC_WARN_CHECK_SWITCH_STATEMENTS = YES
GCC_WARN_SHADOW = YES
GCC_WARN_64_TO_32_BIT_CONVERSION = YES
GCC_WARN_INITIALIZER_NOT_FULLY_BRACKETED = YES
GCC_WARN_ABOUT_RETURN_TYPE = YES
GCC_WARN_MISSING_PARENTHESES = YES
GCC_WARN_ABOUT_MISSING_FIELD_INITIALIZERS = YES
GCC_WARN_ABOUT_MISSING_NEWLINE = YES
GCC_WARN_SIGN_COMPARE = YES
GCC_WARN_UNDECLARED_SELECTOR = YES
GCC_WARN_UNUSED_FUNCTION = YES
GCC_WARN_UNUSED_LABEL = YES
GCC_WARN_UNUSED_VALUE = YES
GCC_WARN_UNUSED_VARIABLE = YES
GCC_WARN_ABOUT_MISSING_PROTOTYPES = YES
GCC_WARN_TYPECHECK_CALLS_TO_PRINTF = YES
GCC_WARN_ABOUT_DEPRECATED_FUNCTIONS = YES
GCC_WARN_HIDDEN_VIRTUAL_FUNCTIONS = YES
GCC_WARN_ABOUT_INVALID_OFFSETOF_MACRO = YES
GCC_WARN_NON_VIRTUAL_DESTRUCTOR = YES
GCC_TREAT_WARNINGS_AS_ERRORS = YES
RUN_CLANG_STATIC_ANALYZER = YES

Peter wrote a great explanation of why you’d want most of these warnings, which I’m not going to attempt. I’ve added some C++ warnings, too. They don’t do anything with clang 1.6, but might be useful in the future.

A few notes:

• Like Peter, I don’t turn on GCC_WARN_UNUSED_PARAMETER. Although you can add __unused to each parameter to disable the warning, doing so breaks Xcode’s code formatting. I use code formatting constantly, so anything that breaks it isn’t acceptable.
• The warnings that were the most painful to turn on were GCC_WARN_64_TO_32_BIT_CONVERSION and GCC_WARN_SIGN_COMPARE. If you use int and NSInteger interchangeably, you’re going to have a tough time with these. (I don’t, but some of the internal libraries I use do.) These are also some of the more dangerous warnings to fix; if you’ve got automated tests, you should run them after every few corrections.
• RUN_CLANG_STATIC_ANALYZER will roughly double (or more) the time your project takes to compile. I consider this a good trade: I rarely trigger a static analyzer warning now, but when I do I want to fix it.
• Also note the GCC_TREAT_WARNINGS_AS_ERRORS. If you are applying these to an existing project, you may start with hundreds of warnings. You’ll probably want to start with this set to NO and change it to YES after you’ve fixed the warnings.
• Remember, too, that this changes the defaults for settings. You can still specify different settings in the build configuration! If the static analyzer is taking too long to run in one project, just turn it off in that one project but leave the .xcconfig file alone!