Comments on: Warnings I turn on, and why

By: Sean M

Sean M — Wed, 03 Mar 2010 22:29:27 +0000

I once spent quite some time trying to enable as many warnings as possible by scouring the gcc man page. Below is my .xcconfig file that contains various warning flags. When Xcode has a specific option for a warning, I use it, if it doesn't exist I use the gcc flag. Note that some warnings do/don't work with some compilers. Our large Obj-C/Obj-C++ app builds warning-free with these settings. (RR is our company prefix, BW stands for Build Warning). This assumes gcc 4.2 and Xcode 3.2. Hope it's helpful.

// C only warnings.
GCC_WARN_ABOUT_MISSING_PROTOTYPES = YES
RR_BW_C_NOTCLANG = -Wdiv-by-zero
RR_BW_C = -Wstrict-prototypes -Wold-style-definition -Wnested-externs -Wmissing-prototypes -Wmissing-declarations $(RR_BW_C_NOTCLANG)
OTHER_CFLAGS = $(RR_BW_C)

// C++ only warnings.
GCC_WARN_HIDDEN_VIRTUAL_FUNCTIONS = YES
GCC_WARN_ABOUT_INVALID_OFFSETOF_MACRO = YES
GCC_WARN_NON_VIRTUAL_DESTRUCTOR = YES
RR_BW_CPP = -Wabi -Wctor-dtor-privacy -Wsign-promo -Woverloaded-virtual
OTHER_CPLUSPLUSFLAGS = $(RR_BW_CPP)

// Objective C only.
GCC_WARN_STRICT_SELECTOR_MATCH = YES
GCC_WARN_UNDECLARED_SELECTOR = YES
RR_BW_OBJC = 

// For all C-based languages.
GCC_WARN_FOUR_CHARACTER_CONSTANTS = YES
GCC_WARN_ABOUT_MISSING_NEWLINE = YES
GCC_WARN_ABOUT_DEPRECATED_FUNCTIONS = YES
GCC_WARN_SHADOW = YES
GCC_WARN_CHECK_SWITCH_STATEMENTS = YES
GCC_WARN_INITIALIZER_NOT_FULLY_BRACKETED = YES
GCC_WARN_MISSING_PARENTHESES = YES
GCC_WARN_SIGN_COMPARE = YES
GCC_WARN_TYPECHECK_CALLS_TO_PRINTF = YES
GCC_WARN_ABOUT_RETURN_TYPE = YES
GCC_WARN_64_TO_32_BIT_CONVERSION = YES

// Managed Object Model compiler.
MOMC_NO_INVERSE_RELATIONSHIP_WARNINGS = YES

// Note that it is important to start with -Wall and -Wextra because if they were at the end, they may reset some other options.
RR_BW_ALL_NOTCLANG = -Wlarger-than-30000 -Winvalid-pch
RR_BW_ALL_NOTGCC40 = -Wstrict-overflow=2 -Wvolatile-register-var -fdiagnostics-show-option
RR_BW_ALL = -Wall -Wextra -Wundef -Wendif-labels -Wpointer-arith -Wcast-align -Wwrite-strings -Wformat=2 -Wno-format-nonliteral -Wmissing-format-attribute -Wpacked -Wredundant-decls -Wdisabled-optimization -Wno-strict-aliasing -Wfloat-equal -Winit-self -Wextra-tokens -Wmissing-field-initializers $(RR_BW_ALL_NOTGCC40) $(RR_BW_ALL_NOTCLANG)

// Warnings to enable occasionally.  They give some good warnings, but not always.
//GCC_WARN_EFFECTIVE_CPLUSPLUS_VIOLATIONS = YES
//RR_BW_ALL_OCCASIONAL = -Wcast-qual -Wunsafe-loop-optimizations -funsafe-loop-optimizations -Wswitch-enum -Wstack-protector -Wformat-nonliteral

// Combine.
WARNING_CFLAGS = $(RR_BW_ALL) $(RR_BW_OBJC)

// TODO: would like to use:
//  GCC_WARN_PEDANTIC = YES • too annoying with Obj-C
//  -Wcast-qual • gives false positives with Obj-C 4625600. But turn on periodically, as it finds real problems!
//  -Wstrict-aliasing • is unnecessarily annoying 5509903 5509977
//  -Wstrict-aliasing=2 would be even nicer, though it is documented to give false positives
//  -Wformat-nonliteral (part of -Wformat=2) • causes problems with NSLocalizedStringFromTable 6835692

By: Jonathan Mitchell

Jonathan Mitchell — Wed, 09 Dec 2009 14:47:13 +0000

Personally I like the unused parameter warning.

Yes, it creates, a log of pragma clutter, especially for callbacks, but when reviewing code I find that those pesky pragmas do provide a bit of instant feedback that would otherwise escape me.

The Apple docs on warnings are helpful too.
http://developer.apple.com/tools/xcode/compilercodewarnings.html

Good post.

By: Uli Kusterer

Uli Kusterer — Tue, 01 Dec 2009 09:19:52 +0000

The Four-Character Literals warning isn't completely pointless. Since they're essentially an Apple addition to C, you want that warning turned on in cross-platform code. So, I wouldn't say "for no benefit", I'd say "I'm writing Mac-only code, so don't need it."

By: Ahruman

Ahruman — Sat, 28 Nov 2009 17:18:04 +0000

I habitually set “-Wall -Wextra -Wno-unused-parameter” in Other Warning Flags, and turn on Treat Warnings as Errors (or -Werror if you like to copy and paste). The only downside is I sometimes need to deal with other people’s code. :-)

By: Uli Kusterer

Uli Kusterer — Mon, 09 Nov 2009 15:39:14 +0000

Re: Treat Warnings as Errors:

If you can use that, do it. But I can't use that in most of my shipping projects, because they need to build and run on several platforms (10.4, 10.5, 10.6 ATM), and Apple's been madly changing their compilers with each version of Xcode, so I get warnings about settings that used to be necessary to build correctly, and are now deprecated, that would stop the build immediately :-(

By: Blake C.

Blake C. — Mon, 09 Nov 2009 04:29:16 +0000

Peter: That's better than editing all of those settings for each project, but you make a good point. I'd say file a bug :)

By: Christopher Lloyd

Christopher Lloyd — Mon, 09 Nov 2009 02:11:18 +0000

"Multiple Definition Types for Selector" is only relevant for the GNU Objective-C runtime which has the mis-feature of trying to associate types with a selector. Largely pointless these days, should probably be deprecated all together.

By: Peter Hosey

Peter Hosey — Mon, 09 Nov 2009 01:03:08 +0000

Blake: That still requires copying the configuration file(s) into every project directory and configuring every project to use them.

By: Jesper

Jesper — Sun, 08 Nov 2009 23:38:58 +0000

dave: Select either your entire project (the blueprint icon at the top) or a specific target in the Groups & Files list in your Xcode project, then choose Get Info from the right click menu. You change these settings on the Build tab; just watch out for the selected Configuration at the top.

For more information, see http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/A_Tour_of_Xcode/010-Xcode_Features_Overview/FeaturesTake2.html#//apple_ref/doc/uid/TP30000890-CH220-SW17 . That whole document ("A Tour of Xcode") is worth reading since you're new to it.

By: dave

dave — Sun, 08 Nov 2009 22:06:23 +0000

I'm a bit of an xcode noob, so forgive my noobishness...
How do I change these settings? I found references to some of them in the xcode build settings reference, not sure where to go from here.

By: Blake C.

Blake C. — Sun, 08 Nov 2009 21:32:24 +0000

Peter and Amagrammer, you can do that with xcconfig files:

http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/XcodeBuildSystem/400-Build_Configurations/build_configs.html

Look for the "Build Configuration Files" section.

By: Peter Hosey

Peter Hosey — Sun, 08 Nov 2009 15:45:21 +0000

julian: No idea.

Amagrammer: Nope. Every “New” project is actually a copy of a project template, with a few variables (e.g., product name) replaced with values. You would have to change the templates, or create new ones.

By: Amagrammer

Amagrammer — Sun, 08 Nov 2009 15:39:33 +0000

Thanks for the quick response. Now maybe you can tell me: is there a way to make those settings the defaults for all projects created in the future? I already have about a dozen projects -- just going into the old ones to make those changes will be tedious enough without having to do it on the new ones as well. Thanks

By: julian

julian — Sun, 08 Nov 2009 13:12:09 +0000

so which one of these aren't contained in -Wmost?

By: Peter Hosey

Peter Hosey — Sun, 08 Nov 2009 05:03:22 +0000

Yup. In Xcode 3.2, the build setting's human-readable name is simply “Undeclared Selectors”. Its under-the-hood name is GCC_WARN_UNDECLARED_SELECTOR, in case you'd like to turn it on now in advance of upgrading. (I doubt Xcode 3.1 will use it, but the setting won't hurt anything, either; Xcode 3.1 will just ignore it.)