Year-end Cleaning (ie. on warning options)
Benjamin Otte recently blogged
about compiler warning options. Now, to use or not to use
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:
These ones I've used in the past but have disabled for one reason or the other:
There are two that stand out:
is not a warning flag strictly speaking, but it's as good as one.
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,
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
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: gcc, vte, warnings