From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21518 invoked by alias); 6 Feb 2002 03:19:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21466 invoked from network); 6 Feb 2002 03:19:47 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 6 Feb 2002 03:19:47 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id 5CFF7F28BE; Tue, 5 Feb 2002 22:19:47 -0500 (EST) To: gdr@codesourcery.com, tim@hollebeek.com Subject: Re: a warning to implement Cc: Dautrevaux@microprocess.com, aoliva@redhat.com, coola@ngs.ru, dewar@gnat.com, gcc@gcc.gnu.org, pcarlini@unitus.it Message-Id: <20020206031947.5CFF7F28BE@nile.gnat.com> Date: Tue, 05 Feb 2002 19:24:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2002-02/txt/msg00323.txt.bz2 <> -Wall sounds to an uninitiated chap like me that it would turn on all warnings. That sounds useful to me. I would be surprised to find that there were useful warnings it did not turn on. Sure in some cases there can be an argument to leave things out of -Wall, but I think that anything that is clearly labeled as undefined in effect should be included in -Wall, because really here the warning is that you are straying outside the standard. Of course not all warnings are about undefined constructs, some are about constructs that are defined, but dubious, e.g. a statement that does nothing at all. But for constructs that are clearly undefined, I think -Wall should include warnings about them where possible.