From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2662 invoked by alias); 25 Feb 2009 13:53:23 -0000 Received: (qmail 2639 invoked by uid 22791); 25 Feb 2009 13:53:21 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail-forward2.uio.no (HELO mail-forward2.uio.no) (129.240.10.71) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Feb 2009 13:53:14 +0000 Received: from exim by mail-out2.uio.no with local-bsmtp (Exim 4.69) (envelope-from ) id 1LcKCC-00048z-Pw for gcc-help@gcc.gnu.org; Wed, 25 Feb 2009 14:53:08 +0100 Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1LcKC8-00048M-De; Wed, 25 Feb 2009 14:53:04 +0100 Received: from cma-eivindlm.uio.no ([129.240.223.140] helo=ichi) by mail-mx5.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1LcKC7-0000gl-TM; Wed, 25 Feb 2009 14:53:04 +0100 Date: Wed, 25 Feb 2009 13:53:00 -0000 To: tstdenis@ellipticsemi.com Subject: Re: Re: Where did the warning go? From: "Eivind LM" Cc: "gcc-help@gcc.gnu.org" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <.1235521396@magma.ca> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <.1235521396@magma.ca> User-Agent: Opera Mail/9.63 (Linux) X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0E09F274298E2EE24CFBEC819CF72BC99E973C8B X-UiO-SPAM-Test: remote_host: 129.240.223.140 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 572 max/h 82 blacklist 0 greylist 0 ratelimit 0 X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2009-02/txt/msg00211.txt.bz2 On Wed, 25 Feb 2009 01:23:16 +0100, Tom St Denis wrote: > On Tue 24/02/09 7:09 PM , "Eivind LM" eivliste@online.no sent: >> I'm sure there are several opinions on what "annoying" and "useless" >> warnings are. A warning can only annoy me if I don't do anything about >> it. >> And "unlikely to be wrong" is not sufficient for me to consider the >> warning to be useless. >> > > Yeah, the problem is you can have warnings for things that don't need > warnings. > Like for example: > > int a; > a = 4; > > warning: the variable name "a" is too short, and doesn't contain the > letter 'e' That is an example of a meaningless warning, and I would simply disable it if it was implemented. No big deal. If I felt like it, I would write an email to the gcc list and ask why anyone had implemented such a warning. Anyway, I am sure GCC developers do their best to write warnings that point on actual potential problems. Likely problems as well as unlikely problems. > Is a "valid" warning, since a conforming compiler may produce ANY > warning it want > (the spec only specifies what warrants a diagnostic (error)). Now if > GCC emitted > that warning would you find that useful? Or perhaps would it get in the > way of > real work? It would probably take me 1 minute to disable the warning, then it would never bother me again. > Now onto something less trivial ... > > char a = 'b'; > > You're assigning an "int" type to a char. splint will warn you about > this, even > though it's perfectly reasonable and well understood [not to mention > portable] > code. Is that useful? I'll repeat myslelf: If the compiler can guarantee that I don't loose precision in the assignment, then I don't want a warning. In this case 'b' is a symbolic constant for the integer value 98, which can be perfectly represented as a char. So I don't want a warning. However, if I have int a; ask_user(&a); char b = a; then I think a warning is in place. If splint gives a warning for the first case, then I would say that is a problem with splint. But I have never tried splint, and probably won't either since you so strongly discourage it :) > In your own example passing 2.5 to a function declared with an int > parameter. > That has well defined behaviour as well. It's no less defined than say > passing > "5" to a function that accepts a long. As I wrote earlier, I consider these as two totally different things. In the first case, the value is changed. In the second case, the value is not changed. The first case might have well defined behaviour. But anyway, my value is changed by 20%. If I wanted to skip the decimals from 2.5, then I would have casted the value to an int explicitly. That's why I want a warning in the cases where any of my values are implicitly changed. This is my personal preference. I am not telling you which warnings you should use when you compile your own code, or which should be default in GCC. I am just saying that 1) I would like to have a warning whenever an implicit conversion happens that might be "value destroying". And 2) since I consider this a serious issue, then I expect the other warnings in GCC (probably also those warnings that I am not aware of) to be serious as well. That's why I would like to enable the whole lot to find out what they can teach me. >> I take all warnings as an opportunity to learn some specific details >> about >> the language. I am a novice, and trust the GCC developers have a good >> reason to write each warning. It is usually easy to get the idea of the >> possible problem when a warning triggers in my own code. Then I either >> find out that the problem can absolutely never ever affect me (and then >> I >> would disable the warning), or I change my code. I have never been sure >> enough yet to disable any of the warnings I have seen so far. > > The goal of good warnings is to detect things that are likely to be > bugs, or are > at least undefined behaviour. Not to warn about things that have > clearly defined > behaviours. So you are saying that the unlikely cases are less serious? Like the int to char assignment, that works fine because the int is *likely* to be in [0,255]? Then it turns out that the int can be 256 before assignment to char, in a very special corner case. How serious this is does not depend on how likely it is. Generally, I would rather say less likely cases are more serious than high likely cases. The highly likely cases are usually easy to discover while testing the software anyway. The less likely cases are the ones that are hard to find when you test, and the most hard-to-debug problems you receive after release. So I won't say nothanks if GCC have ability to warn me about the less likely cases. > If you want to learn more about C, pick up the ISO C draft and read > it. Don't rely on the warnings from GCC to teach you what is and isn't > good C code. I have Bjarne's book for C++, and think it is a great reference. But I can't go about reading the whole thing and expect to be a fluent C++ programmer the next day. There are several ways to learn. One good way for me is if possible problems in my own code are pointed out to me as early as possible. That way I can look up in the book to find what the problem is, and consider whether the problem is a real issue or not. Afterwards, I will actually remember what I read in the spec, since it was directly related to my own code. >> I do of course think differently if I work with old code that has too >> many >> warnings to fix. But encouraging everyone to compile their new code with >> as many warning flags as possible could eventually solve that problem? >> :) > > It is indeed a good goal to have warning free code, but adding mindless > and > useless casts everywhere (for instance) is just as annoying coding > practice. I > wouldn't accept code that read, like > > char a = (char)'b'; I think I understand your concern. But once again, I don't think a cast is mindless or useless if it actually changes the data value. The above cast does not change the data value, and I agree it should not be neccesary. > As it's superfluous and will make reading the code harder, not easier. > > It's why a lot of people avoid tools like splint (if their corporate > masters > don't dictate it's use) because 99 out of 100 times the warnings > produced don't > lead to anything that could even remotely possibly be a bug. It's > irresponsible > to trace down and "fix" what isn't broken. Specially when there are > better tools > out there like valgrind to help debug your apps. > >> Anyway, we don't have to agree on this. I just wish to have a flag that >> let me compile my own code with as many warnings as possible. And then >> the >> name of the -Wall flag is in the way. > > I'm trying to help you by persuading you that that's not a good idea. > Learn the > C standard and code within it's boundaries. Don't rely on superfluous > warnings > to avoid bugs because at the end of the day it's not a sufficient > condition for > bug free code to be splint warning free. I agree it takes more than just warning-free to be bug-free. But some of the hard-to-debug bugs can be avoided by warnings, so I want to use the warnings for all they are worht. But we definitely have very different ideas about this, and probably won't get any closer to agree. But thanks for your opinions though, I learned a lot! :) Eivind