Behdad Esfahbod's daily notes on GNOME, Pango, Fedora, Persian Computing, Bob Dylan, and Dan Bern!

My Photo
Name:
Location: Toronto, Ontario, Canada

Ask Google.

Contact info
Google
Hacker Emblem Become a Friend of GNOME I Power Blogger
follow me on Twitter
Archives
July 2003
August 2003
October 2003
November 2003
December 2003
March 2004
April 2004
May 2004
July 2004
August 2004
September 2004
November 2004
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
October 2008
November 2008
December 2008
January 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
November 2009
December 2009
March 2010
April 2010
May 2010
June 2010
July 2010
October 2010
November 2010
April 2011
May 2011
August 2011
September 2011
October 2011
November 2011
November 2012
June 2013
January 2014
May 2015
Current Posts
McEs, A Hacker Life
Saturday, December 27, 2008
 Year-end Cleaning (ie. on warning options)

Benjamin Otte recently blogged about compiler warning options. Now, to use or not to use -Werror is something Benjamin and I have wasted hours discussing, but that's not the point here.

The reason that I thought I blog and link to his post is that compiler warnings are very useful tools for writing good code. These days, when I run my C code, it typically works the first time. That's not as much a complement to me as it is to my compiler. That's because by the time I finish fixing all the warnings, all the trivial bugs are gone too. Any C programmer must have a large set of warning options he enables, and here is mine:

-fno-common
-Wall
-Wdeclaration-after-statement
-Wextra
-Wformat=2
-Winit-self
-Winline
-Wpacked
-Wp,-D_FORTIFY_SOURCE=2
-Wpointer-arith
-Wlarger-than-65500
-Wmissing-declarations
-Wmissing-format-attribute
-Wmissing-noreturn
-Wmissing-prototypes
-Wnested-externs
-Wold-style-definition
-Wredundant-decls
-Wsign-compare
-Wstrict-aliasing=2
-Wstrict-prototypes
-Wswitch-enum
-Wundef
-Wunreachable-code
-Wunsafe-loop-optimizations
-Wwrite-strings


These ones I've used in the past but have disabled for one reason or the other:

-Wbad-function-cast
-Werror-implicit-function-declaration
-Wfloat-equal
-Wmissing-field-initializers
-Wmissing-include-dirs
-Wswitch-default


There are two that stand out: -fno-common is not a warning flag strictly speaking, but it's as good as one. -Wp,-D_FORTIFY_SOURCE=2 is not a warning flag either, but it enables some extra checks in glibc headers.

Benjamin's post explains each warning he uses and why it's a good idea. When in doubt, man gcc is your friend.

Now, the trick to using these is to always remember that these are warnings. Some will trigger in very legitimate code. That's why -Werror is evil. Warning flags are a very personal thing. I don't like cluttering code I maintain with them.

Anyway, I went ahead and fixed all warnings that Pango and Vte compilation generated. Now I can see if my new code generates a warning. Yay.

Speaking of vte, it has been seeing some new development. Last month I wrote a pangocairo rendering backend for it. Later I implemented support for combining characters. That wasn't easy as the vte code has a one-char-per-cell model hardcoded all over the code. I retro-fitted more-than-one-char-per-cell on it vy using a new data type called vteunistr. ChPe has been adding new API, including adding GObject properties. And we all have been ripping old code out. Here is the summary of changes for the past six weeks:
99 files changed, 6317 insertions(+), 14094 deletions(-)

Labels: , ,

Comments:
One thing I really miss from other compilers when I use gcc is disabling warnings via pragmas. That way you can enable somehting like -Werror and just special case the few instances where a warning is legitimate (I'd argue if it's more than a few cases then the warning isn't worth using).

I've found that with big projects if you don't use -Werror you end up with lots of warnings that could be fixed, but simply aren't because people always "leave it for later".
 
Post a Comment



<< Archive
<< Home