AWARE: All Warnings Are Really Errors

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AWARE: All Warnings Are Really Errors

Olaf Meeuwissen-4
Hi list,

In an earlier post[1] 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[2] for 1.0.26 a while back.  Now, I have also started making
some headway on a "canonical setup" where warnings should be fixed[3].

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[4] that produced but pretty quickly discovered that my "fixes"
triggered warnings when running a plain

  make

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

  -W
  -Wall
  -Wcast-align
  -Wcast-qual
  -Wmissing-declarations
  -Wmissing-prototypes
  -Wpointer-arith               # included in -pedantic, see [5]
  -Wreturn-type                 # included in -Wall, see [5]
  -Wstrict-prototypes
  -pedantic                     # depends on C language standard, still
                                # using -ansi but will switch to C99[2]

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.

 [1] http://lists.alioth.debian.org/pipermail/sane-devel/2015-September/033930.html
 [2] https://gitlab.com/sane-project/backends/milestones/1
 [3] https://gitlab.com/sane-project/ci-envs
 [4] git log -p 497d591..fff1c59
 [5] https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Warning-Options.html#Warning-Options

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
https://my.fsf.org/donate                        https://my.fsf.org/join
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9

--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Loading...