[Bug c/38961] New: if () block not true but a command in it is still in effect

[Bug c/38961] New: if () block not true but a command in it is still in effect

[jellegeerts at gmail dot com]

Complete command line that triggered the bug: gcc -v -save-temps -ansi -Wall
-Wextra -Werror -pedantic -pedantic-errors -g -O2 -o gcc_bug gcc_bug.c

Output of the command line:
**********************
Reading specs from /usr/lib/gcc/i486-slackware-linux/4.2.4/specs
Target: i486-slackware-linux
Configured with: ../gcc-4.2.4/configure --prefix=/usr --enable-shared
--enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
--enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose
--with-arch=i486 --target=i486-slackware-linux --host=i486-slackware-linux
Thread model: posix
gcc version 4.2.4
 /usr/libexec/gcc/i486-slackware-linux/4.2.4/cc1 -E -quiet -v gcc_bug.c
-mtune=i486 -march=i486 -ansi -Wall -Wextra -Werror -pedantic -pedantic-errors
-fworking-directory -O2 -fpch-preprocess -o gcc_bug.i
ignoring nonexistent directory
"/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../../i486-slackware-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/i486-slackware-linux/4.2.4/include
 /usr/include
End of search list.
 /usr/libexec/gcc/i486-slackware-linux/4.2.4/cc1 -fpreprocessed gcc_bug.i
-quiet -dumpbase gcc_bug.c -mtune=i486 -march=i486 -ansi -auxbase gcc_bug -g
-O2 -Wall -Wextra -Werror -pedantic -pedantic-errors -ansi -version -o
gcc_bug.s
GNU C version 4.2.4 (i486-slackware-linux)
        compiled by GNU C version 4.2.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d3491cea3997204b3b932c449c79b80e

/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../../i486-slackware-linux/bin/as
-V -Qy -o gcc_bug.o gcc_bug.s
GNU assembler version 2.18.50.0.9 (i486-slackware-linux) using BFD version
(Linux/GNU Binutils) 2.18.50.0.9.20080822
 /usr/libexec/gcc/i486-slackware-linux/4.2.4/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o gcc_bug
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../crt1.o
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../crti.o
/usr/lib/gcc/i486-slackware-linux/4.2.4/crtbegin.o
-L/usr/lib/gcc/i486-slackware-linux/4.2.4
-L/usr/lib/gcc/i486-slackware-linux/4.2.4
-L/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../../i486-slackware-linux/lib
-L/usr/lib/gcc/i486-slackware-linux/4.2.4/../../.. gcc_bug.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i486-slackware-linux/4.2.4/crtend.o
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../crtn.o
**********************

The source code that triggered the bug:
**********************
#include <stdio.h>
#include <string.h>

const char *logout_cmd = NULL;

static void foo()
{
        const char *logout_cmd = logout_cmd;

        if ( ! logout_cmd )
        {
                /* This line is not executed. */
                printf("line %d, logout_cmd = %s\n", __LINE__, logout_cmd);

                /* This line is not executed when stepping through the code
                 * with gdb, but logout_cmd still is assigned the value
                 * "lxsession-logout", possible optimization bug? */
                logout_cmd = "lxsession-logout";
        }

        printf("line %d, logout_cmd = %s\n", __LINE__, logout_cmd);

        if (strcmp(logout_cmd, "openbox --exit"))
                printf("gcc bug triggered\n");
}

int main(void)
{
        printf("line %d, logout_cmd = %s\n", __LINE__, logout_cmd);

        logout_cmd = "openbox --exit";

        printf("line %d, logout_cmd = %s\n", __LINE__, logout_cmd);

        foo();

        printf("line %d, logout_cmd = %s\n", __LINE__, logout_cmd);

        return 0;
}
**********************


-- 
           Summary: if () block not true but a command in it is still in
                    effect
           Product: gcc
           Version: 4.2.4
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jellegeerts at gmail dot com
  GCC host triplet: i486-slackware-linux


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

[falk at debian dot org]

------- 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

[Bug c/38961] if () block not true but a command in it is still in effect

[jellegeerts at gmail dot com]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[jellegeerts at gmail dot com]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[jellegeerts at gmail dot com]

------- 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

[pinskia at gmail dot com]

------- 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"
<gcc-bugzilla@gcc.gnu.org 
 > 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

[Andrew Thomas Pinski]

Sent from my iPhone

On Jan 24, 2009, at 2:24 PM, "jellegeerts at gmail dot com" <gcc-bugzilla@gcc.gnu.org 
 > 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

[jellegeerts at gmail dot com]

------- 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

[jellegeerts at gmail dot com]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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