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
next prev parent 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).