public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Eivind LM" <eivliste@online.no>
To: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Subject: Re: Where did the warning go?
Date: Tue, 24 Feb 2009 14:03:00 -0000	[thread overview]
Message-ID: <op.upuz2ss0jwclfx@ichi> (raw)
In-Reply-To: <m3ocwsj3bd.fsf@google.com>

On Mon, 23 Feb 2009 21:39:18 +0100, Ian Lance Taylor <iant@google.com>  
wrote:

> "Eivind LM" <eivliste@online.no> writes:
>
>> Next question: Does the -Wall flag have a long and complicated history?
>
> No, though certainly the details have changed over time.

So the flag enables a subset of all warnings, and the collection changes  
over time. Why don't the name reflect that? I think Eljay's suggested name  
"-Wselect-popular-warnings" was excellent.

>> The name indicates that it enables ... well, uh, ... *all* warnings.  
>> (Yes,
>> i should have read the docs more carefully.)
>
> As the docs say, -Wall enables all warnings which can be easily avoided
> by changing the soure code.

It is useful to have a flag like that, but the the name should really be  
something else than -Wall.

>> I would like to compile my code with absolutely as many compiler  
>> warnings
>> enabled as possible, and then selectively deactivate the ones that I
>> cannot avoid in a reasonable way.
>
> That is pretty much the goal of -Wall.
>
> The warnings which are not included in -Wall are either difficult to
> avoid in some cases or are specific to certain programming styles.

It does of course depend on each case whether a warning is easy to avoid  
or not, and also if it warns about a real problem or not. But in any case,  
a warning can help me write code that more surely will do what I intend.  
For example the following code is not doing what I intended:

   #include <stdio.h>
   void print(int a) { printf("%d\n", a); };
   int main() { print(2.5); return 0; };

I think the problem in the code is both easy to avoid and serious, but I  
get no warning with -Wall and -Wextra (g++ 4.3).

Instead of adding -Wconversion (and to search for any other flags I might  
find useful, but that I don't know of yet), I would rather compile my  
project with something like "-Weverything" from the beginning, and then  
disable the warnings that turns out to not fit my programming style.

>> Is there a way to enable absolutely all? -Weverything? :)
>
> No, that would not be useful.  Nobody writes code in the intersection of
> all the programming styles supported by all the warning options.

I am sure you are right about this, so maybe -Weverything is not the right  
thing. But my point is that it is better to start off with "everything",  
and disable the ones you don't want for a given project, than to start  
with only a selected set of warnings.

Because if you are using -Wall then:
a) You don't know which warnings you are missing out on.
b) You might risk loosing a warning you were used to have (unless you are  
always reading the changelog for new gcc versions)

> We are certainly open to changing the ways that the warnings are
> aggregated into -Wall and -Wextra, including adding a new aggregation
> warning if it seems useful.  However, -Weverything is unlikely to be
> accepted.

If -Weverything is impossible, then I wish a flag that enables every  
single warning that might be relevant for my programming style. Probably  
others would want this for their programming styles too. But if there are  
too many different programming styles to have -Weverything-style-*, then  
how about having -Weverything anyway, and let people disable warnings that  
don't fit with their style?

I'm glad to hear that you are open for changes, and also very grateful  
that you took the time to reply thoroughly to my email.

Thanks,
Eivind
PS, did I mention that -Wall should be renamed? :)

  reply	other threads:[~2009-02-24 14:03 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 [this message]
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
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=op.upuz2ss0jwclfx@ichi \
    --to=eivliste@online.no \
    --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).