From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20585 invoked by alias); 15 Dec 2004 09:00:27 -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 20037 invoked from network); 15 Dec 2004 09:00:14 -0000 Received: from unknown (HELO mail.dev.rtsoft.ru) (80.240.96.70) by sourceware.org with SMTP; 15 Dec 2004 09:00:14 -0000 Received: (qmail 7424 invoked from network); 15 Dec 2004 08:32:38 -0000 Received: from unknown (HELO ?192.168.1.213?) (192.168.1.213) by mail.dev.rtsoft.ru with SMTP; 15 Dec 2004 08:32:38 -0000 Message-ID: <41C009AA.4020700@dev.rtsoft.ru> Date: Wed, 15 Dec 2004 09:00:00 -0000 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 MIME-Version: 1.0 To: 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> In-Reply-To: <41BF1C0A.6060100@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00563.txt.bz2 Nathan Sidwell wrote: > Dmitry Antipov wrote: > >> w.c: In function `f': >> w.c:5: warning: 'z' might be used uninitialized in this function >> >> which is not true. > > 'tis true too, just here. > return x + y + z; Oops. That's my mistake, both examples are incorrect :-(. It should be (with line numbers, for referencing lines) 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 } in the first case and 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 y += z; 11 return x + y; 12 } in the second, respectively. > read the documentation for -Wuninitialized, which will explain > why it can't get all the cases correct. I've taken a look through 3.4.3. docs online. The docs describes two different cases: > { > int x; > switch (y) > { > case 1: x = 1; > break; > case 2: x = 4; > break; > case 3: x = 5; > } > foo (x); > } > > If the value of y is always 1, 2 or 3, then x is always initialized, but GCC doesn't know this. This sample probably means that we have something like: void bar (int y) { int x; switch (y) { case 1: x = 1; break; case 2: x = 4; break; case 3: x = 5; } foo (x); } If 'bar()' has the global scope (can be called from another modules), it's impossible to predict the value of 'y', and we should warn always. But, if the bar is 'static', we can look through all calls of the 'bar()' and do the following check for each call: if (argument of 'bar()' is a compile-time constant) { if (argument of bar is not 1, 2, or 3) warn (); } else warn (); IMHO, this kind of check may be really useful. The second example from documentation > { > int save_y; > if (change_y) save_y = y, y = new_y; > ... > if (change_y) y = save_y; > } is similar to my sample #1 (except that this example implicitly assumes that 'change_y' isn't changed in the middle code marked as '...'). Probably that's the case which is described with "GCC is not smart enough to see all the reasons why the code might be correct" words in the docs :-). >> Is it reasonable to learn GCC do more analysis in attempt to avoid >> warning in this case ? How is it complex ? > > > it gets as complex as the halting problem :) Really ? Why ? Dmitry