public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tom St Denis <tstdenis@ellipticsemi.com>
To: "John (Eljay) Love-Jensen" <eljay@adobe.com>
Cc: GCC-help <gcc-help@gcc.gnu.org>
Subject: Re: Where did the warning go?
Date: Wed, 25 Feb 2009 13:02:00 -0000	[thread overview]
Message-ID: <49A54157.20701@ellipticsemi.com> (raw)
In-Reply-To: <C5CA94D0.38787%eljay@adobe.com>

John (Eljay) Love-Jensen wrote:
> Hi everyone,
>
> [Tom]> I think most long term developers really just want the warnings for
> two things.  Things that are undefined behaviour, and things that are likely
> a typo...
>
> I don¹t mind keeping -Wall with the current meaning, and not deprecating it.
>
> I, as a long term developer who has been developing for over 30 years, and
> in C/C++ for over 20 years, using GCC since 2.95 came out, do wish that
> there was a -Weverything flag that enabled all -W* toggle warnings.
>   
I'm actually ok with *adding* a new macro flag [e.g. -Weverything].  I 
just don't want the defaults to change so radically.

> Why?
>
> Because I use GCC as a lint-like tool.
>
> I like to be able to see what warnings my code generates, vet those warnings
> and vet my code, then decide to disable the warning or fix my code.
>   
Which sounds reasonable to me.  I don't dismiss things like splint 
because I'm lazy or dislike standards.   My position stems from 
experience with the tools and to this day never finding a bug in my 
software because of it.  -Wall has found bugs, valgrind/gdb have helped 
me find bugs, but never have I ran splint on my code base and actually 
found a bug.

Maybe your situation is different, and I don't dismiss that.

> I deeply appreciate that GCC has taken on incorporating (sensible) lint-like
> functionality into the compiler itself, which uses -Wfoo toggles.  (I can
> even appreciate that -Wall is "select popular warnings", and -Wextra is
> "select additional less popular warnings".)
>
> Right now, I have a command-line for GCC g++ that is very, very, very, very
> long, because I enable the warnings I know about.  But I may have missed one
> or two.  And more may come out with the next version of GCC that I am
> unaware about.
>
> I wish I had a -Weverything flag.
>   
I'd be more interested in better static analysis than more syntax 
warnings.  And GCC has done a bit of that, if for example, you use a 
constant in an array index for an array of known dimensions GCC will 
warn if the value is out of range.  Things like that are more useful I'd 
think.

I guess it also depends on your work flow standards too.  Where I work 
our standards are basically reasonably close to ISO C (except where we 
start doing kernel or embedded work), and pass with the standard set of 
"-Wall -W" flags without warnings. 

Not to say we're 100% defect free, but of the (few) defects we have had, 
extra syntax checks would not have found them.  Typically they'd be 
things like structure size mismatches, off by one errors, etc.

> As long as I'm making wishes, I also wish warnings were emitted like this:
> test.cpp:6: -Wunused warning: unused variable 'u'
> ...rather than...
> test.cpp:6: warning: unused variable 'u'
>
> Just my $0.02.
>   
Perhaps a variant of that where it outputs a code instead and you can 
look it up in a manpage so the output isn't as verbose, e.g.

test.cpp:6: (W43) warning: blah

Where W43 refers to -Wunused or something.

If you want to get on about formatting though, it would be nice to give 
gcc a "I'm in 2009 with an ANSI VT100 terminal can you please highlight 
text for me" option so that file names, line numbers, and the warning 
appear in different colours allowing them to be scanned relatively quickly.

:-)

Tom

  reply	other threads:[~2009-02-25 13:02 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-13 16:07 Eivind Lyche Melvær
2009-02-13 16:27 ` John (Eljay) Love-Jensen
2009-02-13 17:57   ` Eivind LM
2009-02-14  2:25     ` Ian Lance Taylor
2009-02-20 15:39       ` Eivind LM
2009-02-20 16:21         ` John (Eljay) Love-Jensen
2009-02-23 20:39         ` Ian Lance Taylor
2009-02-24 14:03           ` Eivind LM
2009-02-24 14:13             ` Tom St Denis
2009-02-24 15:10               ` Eivind LM
2009-02-24 18:29                 ` Tom St Denis
2009-02-25  0:07                   ` Eivind LM
2009-02-24 15:43             ` John (Eljay) Love-Jensen
2009-02-24 15:52               ` Kevin P. Fleming
2009-02-24 17:52             ` Ian Lance Taylor
2009-02-24 17:58               ` Harvey Chapman
2009-02-25  0:23                 ` Eivind LM
2009-02-25 12:09                   ` Tom St Denis
2009-02-25 12:25                     ` John (Eljay) Love-Jensen
2009-02-25 13:02                       ` Tom St Denis [this message]
2009-02-25 13:17                       ` Andrew Haley
2009-02-25 21:48                       ` Ian Lance Taylor
2009-02-25  0:37               ` Eivind LM
2009-02-25  0:23 Tom St Denis
2009-02-25 13:53 ` Eivind LM
2009-02-25 14:20   ` Tom St Denis
2009-02-25 15:56     ` Eivind LM
2009-02-25 16:16       ` Tom St Denis
2009-02-25 17:16         ` John Z. Bohach

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=49A54157.20701@ellipticsemi.com \
    --to=tstdenis@ellipticsemi.com \
    --cc=eljay@adobe.com \
    --cc=gcc-help@gcc.gnu.org \
    /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).