Jay Carlson wrote: [...] > If it's somebody else's code, you can leave out the -Wall, at least > until you're debugging it. Fixing compiler warnings seems to be the best > return on investment for troubleshooting. There are some warnings it's worth upgrading to errors --- for gcc, we use: -Wall \ -Wextra \ -Werror=implicit \ -Werror=format \ -Werror=pointer-sign \ -Werror=return-type \ -Werror=sequence-point \ -Werror=uninitialized \ -Werror=init-self \ -Werror=write-strings The big important one is -Werror=implicit, which upgrades the C implicit function declaration warning to an error. The C spec is utterly rigid about what errors you're allowed to emit by default, and for hysterical raisins calling a function that hasn't been declared is *not* an error. This catches typos and produces an error at the actual appropriate point in the compilation. The other options catch various other common problems. The full list is here: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html Incidentally, the -Werror option on its own upgrades (nearly) *all* warnings to errors. This can be useful, but never release code with this enabled! Because the C spec does *not* specify what warnings the compiler can produce, which means different compilers produce different warnings, which means that if you treat them as errors you run the risk of your code failing to compile if your user doesn't use the same compiler you use... -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true." --- Master Li Kao, │ _The Bridge of Birds_
Attachment:
signature.asc
Description: OpenPGP digital signature