public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jeffrey Walton <noloader@gmail.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb@sourceware.org
Subject: Re: Switch -Wunused-variable on?
Date: Sun, 22 Apr 2012 22:25:00 -0000	[thread overview]
Message-ID: <CAH8yC8komGQs-Cm7OUPGuz5YOe7ze97xk2NKYnWnjsxDJWzsSA@mail.gmail.com> (raw)
In-Reply-To: <m3bomjy0ov.fsf@redhat.com>

On Sun, Apr 22, 2012 at 4:24 PM, Sergio Durigan Junior
<sergiodj@redhat.com> wrote:
> On Sunday, April 22 2012, Jan Kratochvil wrote:
>
>> On Sun, 22 Apr 2012 09:14:44 +0200, Sergio Durigan Junior wrote:
>>> However, before continuing to prepare this patch, I would like what you
>>> think about enabling -Wunused-variable by default in the building.
>>
>> There are more useful -Wunused* options, GDB uses now:
>>       -Wno-unused -Wunused-value -Wunused-function
>
> Sorry, do you mean that there are more useful -Wunused* flags than
> -Wunused-variable?
>
>> IIRC the counterargument for -Wunused-variable was that GDB contains various
>> #if-compiled code where is a nightmare to get the code right with matching
>> #if-clauses also for the variables being used by various #if-compiled code
>> chunks.  I could not find that mail now in the time I gave to it.
>
> Yes, this is a counter-argument, and I was also thinking about it.  I
> don't know how people prefer to deal with this issue, but something
> like:
>
>    #define USED_VAR(var) ((void) var)
I use this technique when using -Wall. It even works on Visual Studio,
so the technique is portable.

>> I believe more -Wunused* would be worth it, maybe the mail was before Joel
>> started to disable -Werror for releases so that claim about problematic
>> #if-clauses is no longer valid.
>
> Yes, I believe the more useful warnings we have, the better.
In general, you will encounter a lot of resistance to increasing
warning. For example, try to add -Wall -Wextra -Wconversion
-Wstrict-overflow to CFLAGS or CXXFLAGS on some project.

Some even refute the results even when they are valid findings. For
example, when static analysis warned the kernel's sys_prctl was
comparing an unsigned value against less than zero, Jesper Juhl
offered a patch to clean up the code. Linus Torvalds howled “No, you
don't do this... GCC is crap.” For the full discussion, see "[PATCH]
Don't compare unsigned variable for <0 in sys_prctl()"
(http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-11/msg08325.html)
from the Linux Kernel mailing list.

I live and die by GCC's static analysis capabilities. I've got stuff
that has been in the field for years and never taken a bug report or
crashed. But I also validate all parameter in each function (C/C++
makes no guarantees on a call graph), I also check all return values,
assert *everything* in debug builds (the best code is code that debugs
itself), and write negative test cases. I could not care less about
positive test cases since you could hire a kid from a third world
country to copy/paste code that passes positive tests.

If I got pwned as often as the l33t k3rn3l hAck3rz, I would consider
finding a new profession. Worst, the tools are already available to
find an fix most of the low hanging fruit. Arrogance and ignorance is
a big problem in the community...

Jeff

  reply	other threads:[~2012-04-22 22:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-22  8:06 Sergio Durigan Junior
2012-04-22  8:23 ` Jan Kratochvil
2012-04-22 20:25   ` Sergio Durigan Junior
2012-04-22 22:25     ` Jeffrey Walton [this message]
2012-04-23  8:55       ` Jan Kratochvil
2012-04-23 14:30     ` Tom Tromey
2012-04-23 15:49       ` Sergio Durigan Junior
2012-04-23 18:02         ` Pedro Alves
2012-04-23 18:39           ` Michael Eager
2012-04-24 22:11       ` Maciej W. Rozycki
2012-04-25  7:51         ` Andreas Schwab
2012-04-25 15:57           ` Maciej W. Rozycki
2012-04-25 16:50             ` Andreas Schwab
2012-04-25 17:22               ` Maciej W. Rozycki
2012-04-25 18:13                 ` Andreas Schwab
2012-04-25 18:20                   ` Sterling Augustine
2012-04-25 18:52                     ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH8yC8komGQs-Cm7OUPGuz5YOe7ze97xk2NKYnWnjsxDJWzsSA@mail.gmail.com \
    --to=noloader@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=sergiodj@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).