[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-25 11:15 --- The self-init is of course for the case where the -Wuninitialized warning is bogus (which happens). It simply has no effect on whatever undefinedness is in your code - it was added to be a "cheaper" way instead of adding the usual zero-initialization which people do when they get seemingly bogus uninitialized warnings. Yes, I see the situation is somewhat unfortunate here ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #9 from jellegeerts at gmail dot com 2009-01-25 01:54 --- Never mind my last message, misunderstood something. Andrew, you say -Winit-self was added because initing a var by itself was a way to disable the -Wuninitialized warning, but shouldn't -Wuninitialized itself warn about the -Winit-self case? In the end it's still undefined behavior and it makes little sense to allow it (correct me if you have other ideas). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #8 from jellegeerts at gmail dot com 2009-01-25 01:50 --- So actually initializing the variable by itself is a hack which results in undefined behavior because folks wanted to disable the warning, and still everybody thinks this is the way to go? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #7 from pinskia at gmail dot com 2009-01-24 22:33 --- Subject: Re: if () block not true but a command in it is still in effect Sent from my iPhone On Jan 24, 2009, at 2:24 PM, "jellegeerts at gmail dot com" wrote: > > > --- Comment #6 from jellegeerts at gmail dot com 2009-01-24 > 22:24 --- > Seems reasonable, though I'd vote for -Wall to include -Winit-self. > > I actually discovered this because of a bug I found in lxpanel. Now > of course > it's the fault of those developers not to use -Winit-self, but seen > the other > options that -Wall enables, it seems reasonable to also enable - > Winit-self. Except -Winit-self is there because we decided a long time ago initing the variable by itself is a way to disable the uninitization warning. In fact before 3.4 there was no way to get this warning (oh I added this option:) ). Thanks, Andrew Pinsky > > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
Re: [Bug c/38961] if () block not true but a command in it is still in effect
Sent from my iPhone On Jan 24, 2009, at 2:24 PM, "jellegeerts at gmail dot com" > wrote: --- Comment #6 from jellegeerts at gmail dot com 2009-01-24 22:24 --- Seems reasonable, though I'd vote for -Wall to include -Winit-self. I actually discovered this because of a bug I found in lxpanel. Now of course it's the fault of those developers not to use -Winit-self, but seen the other options that -Wall enables, it seems reasonable to also enable - Winit-self. Except -Winit-self is there because we decided a long time ago initing the variable by itself is a way to disable the uninitization warning. In fact before 3.4 there was no way to get this warning (oh I added this option:) ). Thanks, Andrew Pinsky -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #6 from jellegeerts at gmail dot com 2009-01-24 22:24 --- Seems reasonable, though I'd vote for -Wall to include -Winit-self. I actually discovered this because of a bug I found in lxpanel. Now of course it's the fault of those developers not to use -Winit-self, but seen the other options that -Wall enables, it seems reasonable to also enable -Winit-self. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-24 19:37 --- The program is only undefined at runtime, we may not reject the program at compile-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #4 from jellegeerts at gmail dot com 2009-01-24 18:44 --- That is certainly true, but shouldn't GCC (instead of optionally warning) report an error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-24 18:19 --- You are invoking undefined behavior so anything can happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #2 from jellegeerts at gmail dot com 2009-01-24 18:15 --- Yes, I know, but it is still a bug that the if () block is false and the variable is still assigned the "lxsession-logout" value but the printf is not executed. Shouldn't be possible I figured? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #1 from falk at debian dot org 2009-01-24 17:48 --- const char *logout_cmd = logout_cmd; actually initializes the variable with its own (uninitialized) value. You can get a warning about this with "-Winit-self". -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
