More on warning cleanup

More on warning cleanup

[Rich Felker]

Since compilers differ in what warnings they include in -Wall, I'd
like to remove -Wall (followed by a bunch of -Wno-*) from musl's
--enable-warnings and instead individually turn on the warnings we
want. A few weeks ago I worked those out on #musl (based on the GCC
manual's documentation of -Wall and other options) and here's what I
came up with:

-Waddress
-Warray-bounds
-Wchar-subscripts
-Wreturn-type
-Wsequence-point
-Wstrict-aliasing
-Wstrict-overflow
-Wunused-function
-Wunused-variable
-Wunused-label

This list does not include the ones we already have as errors because
they only trigger on invalid C:

-Werror=implicit-function-declaration
-Werror=implicit-int
-Werror=pointer-sign
-Werror=pointer-arith

Are these any other warnings we should enable? I specifically don't
want any from the following list which we're explicitly turning off
after using -Wall right now:

-Wparentheses
-Wuninitialized
-Wmissing-braces
-Wunused-value
-Wunused-but-set-variable
-Wunknown-pragmas
-Wpointer-to-int-cast

Note that the list of warnings to disable after -Wall is almost as
long as my list of desirable warnings to enable.

One other issue to consider is how to get rid of enabled-by-default
warnings we don't want. On GCC they're impossible to turn off
individually, but unobtrusive; only -w can turn them off, but -w is
permanent and overrides all later -W options. On cparser, a lot of
crap is turned on by default, but -w turns it off and is then
overridable by subsequent -W options. Not sure about clang.

Rich

Re: More on warning cleanup

[Alex Dowad]

On 28/05/15 07:08, Rich Felker wrote:
> Since compilers differ in what warnings they include in -Wall, I'd
> like to remove -Wall (followed by a bunch of -Wno-*) from musl's
> --enable-warnings and instead individually turn on the warnings we
> want. A few weeks ago I worked those out on #musl (based on the GCC
> manual's documentation of -Wall and other options) and here's what I
> came up with:
>
> -Waddress
> -Warray-bounds
> -Wchar-subscripts
> -Wreturn-type
> -Wsequence-point
> -Wstrict-aliasing
> -Wstrict-overflow
> -Wunused-function
> -Wunused-variable
> -Wunused-label
>
> This list does not include the ones we already have as errors because
> they only trigger on invalid C:
>
> -Werror=implicit-function-declaration
> -Werror=implicit-int
> -Werror=pointer-sign
> -Werror=pointer-arith
>
> Are these any other warnings we should enable?
Are you interested in warnings provided by clang, but not by gcc? I've 
noticed that there are a few things in musl which clang warns about, but 
gcc doesn't; such as expressions where operator precedence might be 
confusing to some, and indexing into strings using + (it wants you to 
use [] instead).

Re: More on warning cleanup

[Rich Felker]

On Thu, May 28, 2015 at 08:55:24AM +0200, Alex Dowad wrote:
> >Are these any other warnings we should enable?
> Are you interested in warnings provided by clang, but not by gcc?

Possibly.

> I've noticed that there are a few things in musl which clang warns
> about, but gcc doesn't; such as expressions where operator
> precedence might be confusing to some, and indexing into strings
> using + (it wants you to use [] instead).

Only interested in warnings that catch non-portable constructs,
near-certain bugs (e.g. UB if the code is reached), typos (unused
warnings help here), etc.

Not interested in coding style policing, and definitely not interested
in warnings that are intended for JS or Python programmers trying to
write their first C program. :-)

Rich

Re: More on warning cleanup

[Shiz]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

> On 28 May 2015, at 07:08, Rich Felker <dalias@libc.org> wrote:
> 
> Since compilers differ in what warnings they include in -Wall, I'd
> like to remove -Wall (followed by a bunch of -Wno-*) from musl's
> --enable-warnings and instead individually turn on the warnings we
> want.

Sounds like a good idea, if only for consistency between compilers.

> One other issue to consider is how to get rid of enabled-by-default
> warnings we don't want. On GCC they're impossible to turn off
> individually, but unobtrusive; only -w can turn them off, but -w is
> permanent and overrides all later -W options. On cparser, a lot of
> crap is turned on by default, but -w turns it off and is then
> overridable by subsequent -W options. Not sure about clang.

clang mimics this behaviour, for what it’s worth. The only thing that
will enable warnings again is -pedantic-errors, which is rather unfortunate.
I presume GCC behaves the same way.

-S



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: More on warning cleanup

[Rich Felker]

On Thu, May 28, 2015 at 03:57:23PM +0200, Shiz wrote:
> > On 28 May 2015, at 07:08, Rich Felker <dalias@libc.org> wrote:
> > 
> > Since compilers differ in what warnings they include in -Wall, I'd
> > like to remove -Wall (followed by a bunch of -Wno-*) from musl's
> > --enable-warnings and instead individually turn on the warnings we
> > want.
> 
> Sounds like a good idea, if only for consistency between compilers.
> 
> > One other issue to consider is how to get rid of enabled-by-default
> > warnings we don't want. On GCC they're impossible to turn off
> > individually, but unobtrusive; only -w can turn them off, but -w is
> > permanent and overrides all later -W options. On cparser, a lot of
> > crap is turned on by default, but -w turns it off and is then
> > overridable by subsequent -W options. Not sure about clang.
> 
> clang mimics this behaviour, for what it’s worth. The only thing that
> will enable warnings again is -pedantic-errors, which is rather unfortunate.
> I presume GCC behaves the same way.

I think this is a good argument that cparser should have its own
separate option to reset all on-by-default warnings to off, or that it
should just get rid of them -- users who want warnings should pass
-Wall or specific options. I'll pass a link to this thread their way.
If they don't want to change it there are ugly ways we could test for
the behavior (compile code almost certain to get warnings with
-Werror, then see if -w -Wall -Werror also errors).

Rich