In an earlier post to the list I wrote:
> [...] I do subscribe to the (self-invented?) AWARE principle:
> All Warnings Are Really Errors
> As such, warnings should be fixed. I am well aware (no pun intended!)
> of the various versions of various compilers on various platforms all
> having their own ideas of what should and should not be flagged as a
> warning when. That notwithstanding, a project can select a canonical
> setup up, use -Werror there and not release unless the compile passes
> on that setup.
> # Now here's an idea for 1.0.26!
Since then, I have added fixing all compiler warnings to my (personal?)
milestone for 1.0.26 a while back. Now, I have also started making
some headway on a "canonical setup" where warnings should be fixed.
Seeing that there are a "ton of compiler warnings" already, I figured
I'd override the default CFLAGS (with gcc) and use
make CFLAGS="-g -O0 -Werror"
That's right, *no* special warnings enabled at all. Just turning the
default warnings into errors. That was all. I fixed some of the
errors that produced but pretty quickly discovered that my "fixes"
triggered warnings when running a plain
This lead me to wonder what set of warning we should consider targets
for fixing in my "canonical setup" (basically just Debian stable with a
very minimal set of development tools and *no* development libraries,
yet, beyond what gcc requires).
Currently, the following are turned on for gcc by default
-Wpointer-arith # included in -pedantic, see 
-Wreturn-type # included in -Wall, see 
-pedantic # depends on C language standard, still
# using -ansi but will switch to C99
Apart from -W and -Wall, I think all of the above are up for discussion
and I welcome opinions on what should and should not be warned about.
Please keep in mind that switching to C99 is on the plate for 1.0.26 and
that that may affect the behaviour of warning options.
For what it's worth, my "fixes" ran foul of -Wcast-qual. I fixed some
code by casting away the const qualifier (after checking that that was
indeed the Right Thing to do!).
# I later noticed that the pixma backend uses a C++-like CONST_CAST
# macro and liked that a lot. Casting *is* UGLY and it should look
# that way in code to reflect that ;-)
# Using CONST_CAST makes it clear, in code, *why* you cast.
 git log -p 497d591..fff1c59
Looking forward to feedback, opinions and the like. In the mean time,
I'll keep "fixing" -W and -Wall warnings and extend my "canonical setup"
to cover more of the code.
Hope this helps,
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
Support Free Software Support the Free Software Foundation
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
sane-devel mailing list: [hidden email]
Unsubscribe: Send mail with subject "unsubscribe your_password"
to [hidden email]
|Free forum by Nabble||Edit this page|