From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23096 invoked by alias); 15 Dec 2004 12:06:02 -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 22928 invoked from network); 15 Dec 2004 12:05:46 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sourceware.org with SMTP; 15 Dec 2004 12:05:46 -0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 6D92B9617; Wed, 15 Dec 2004 07:05:46 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26930-01-3; Wed, 15 Dec 2004 07:05:46 -0500 (EST) Received: from [127.0.0.1] (taconic.gnat.com [205.232.38.103]) by nile.gnat.com (Postfix) with ESMTP id 3512C9615; Wed, 15 Dec 2004 07:05:46 -0500 (EST) Message-ID: <41C0289C.2000209@adacore.com> Date: Wed, 15 Dec 2004 12:06:00 -0000 From: Robert Dewar User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: Dmitry Antipov Cc: gcc@gcc.gnu.org Subject: Re: Dubious "'foo' might be used uninitialized in this function" message References: <41BF1207.2040102@dev.rtsoft.ru> <41BF1C0A.6060100@codesourcery.com> <41C009AA.4020700@dev.rtsoft.ru> In-Reply-To: <41C009AA.4020700@dev.rtsoft.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00565.txt.bz2 Dmitry Antipov wrote: >> it gets as complex as the halting problem :) > Really ? Why ? Because the general evaluation of compile time contants is clearly in this territory. Your example: 1 #include 2 3 int f (int x, int y) 4 { 5 int z; 6 7 if (x) 8 z = getppid (); 9 y = getpid (); 10 if (x) 11 y += z; 12 return x + y; 13 } requires the compiler to do symbolic evaluation of the tests in lines 7 and 10 and determine that they always have the same truth value. Then you expect the compiler to do an analysis of the flow of the program for the two cases, and determine that everything is OK in both cases. Yes, it is conceivable, though really *quite* difficult to do this in a simple case like this, but obviously impractical/impossible in more complex cases. The compiler is complaining about line 11, because as far as it is concerned, z has not been unconditionally assigned previously. It is simply not in the business of saying "ah, but it's OK, we would never have got to line 11 unless the condition in line 10 was true, in which case the condition in line 7 would have been true, which means that z would have been assigned at line 8". Warnings are warnings, not errors. Usually they are warnings precisely because it is impossible to precisely separate the bad cases from the good cases. The art of warning design is to give as many useful warnings as possible without giving too many false positives, and without requiring any extensive analysis that the compiler is not doing anyway. Here is an example from Ada: 1. generic 2. type R is private; | >>> warning: type "R" is not referenced 3. package Q is 4. X : Integer; 5. end Q; One of our customers recently complained that this was a false positive, because there might be a child unit of Q that references R. This is true. However, after quite a bit of dicussion, we decided that it was useful to retain the warning, since it is rather unusual (though certainly legal) to have entities that are referenced ONLY in a child unit, and if we removed the warning on this basis, we would lose a lot of useful warnings. child unit