Like Tree13Likes

Bug in gcc

This is a discussion on Bug in gcc within the C Programming forums, part of the General Programming Boards category; Originally Posted by laserlight <snip> EDIT: But really, there's no point arguing this. . Fair enough. I have fixed the ...

  1. #16
    11DE784A SirPrattlepod's Avatar
    Join Date
    Aug 2013
    Posts
    485
    Quote Originally Posted by laserlight View Post
    <snip>
    EDIT:
    But really, there's no point arguing this. .
    Fair enough. I have fixed the program, but it still doesn't output the right answer :-(

    Code:
    #include <stdio.h>
     
    const char *usage(int test)
    {
        char s[15];
         
        sprintf(s, "%d\n", test);
        return s;
    }
     
    int main(void)
    
    {
    
        int a;
    
         
    
        a += 100;
    
        printf("a is %s\n", usage(a));
    
    }

  2. #17
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,308
    Quote Originally Posted by SirPrattlepod
    I have fixed the program, but it still doesn't output the right answer
    Refer to post #2:
    Quote Originally Posted by Salem
    You're returning a pointer to a local variable.
    Refer to post #5:
    Quote Originally Posted by vart
    a is uninitialized, so a += 100 is undefined
    Refer to post #8:
    Quote Originally Posted by laserlight
    The variable named s is a non-static local variable. It has automatic storage duration (refer to C99 Clause 6.2.4), i.e., its lifetime is limited to the function. After the return is done, the pointer points to an object for which storage is no longer guaranteed to be reserved. As such, if the storage is say, then zero filled, that would not be a compiler bug.
    And refer to std10093's post #15, with the caveat that the claim that "as a result, there is nothing there. So, sMain points to nothing" is inaccurate.
    SirPrattlepod likes this.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #18
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,694
    Quote Originally Posted by SirPrattlepod View Post
    Fair enough. I have fixed the program, but it still doesn't output the right answer :-(
    We posted the same exact time. See my post before yours. Hope this helps.
    SirPrattlepod likes this.
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  4. #19
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,694
    Quote Originally Posted by laserlight View Post
    And refer to std10093's post #15, with the caveat that the claim that "as a result, there is nothing there. So, sMain points to nothing" is inaccurate.
    I tried to explain it simply. Can you advice me how to rephrase it?
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  5. #20
    Registered User
    Join Date
    Jun 2005
    Posts
    6,677
    Quote Originally Posted by std10093 View Post
    Code:
    int main(void)
    {
        int a; /* Declare a variable named a, with no initial value */
         
        /* We add 100 to a. But a has not a value. Thus we add 100 in 
           something we do not know its value and as a result, this 
           line of code means a = 100 + unknownNumber;             */
        a += 100;
    }
    Strictly speaking, std10093, your description here is incorrect.

    Accessing the value of an uninitialised variable yields undefined behaviour - it doesn't just retrieve an unknown value. And accessing the value of a variable is a logical precursor to adding a value to it.

    Practically, what you say is often correct. I did actually encounter a small company who proudly demonstrated their proprietary in-house C compiler to me some years back. Among other things, when code was compiled for debugging, a runtime error would result whenever the value of an uninitialised basic variable (int, char, etc) was accessed. Having that happen when debugging, to say the least, gave a rather pointed object lesson related to uninitialised variables.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  6. #21
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,308
    Usually we just say something like "therefore, the behaviour is undefined". The problem with claiming that there's "nothing there" is that the memory might still contain what was there, and then maybe, just maybe, that memory might be accessed without any apparent problem.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  7. #22
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,694
    Both grumpy and laserlight are correct. Thank you both!
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  8. #23
    Registered User
    Join Date
    Jun 2005
    Posts
    6,677
    Quote Originally Posted by laserlight View Post
    Usually we just say something like "therefore, the behaviour is undefined". The problem with claiming that there's "nothing there" is that the memory might still contain what was there, and then maybe, just maybe, that memory might be accessed without any apparent problem.
    Indeed. I would argue that the nastiest (potential) result of undefined behaviour is what the programmer expects to happen. After all, if the programmer gets the result s/he expects, s/he might be deceived into believing the code is correct. This results in subtle bugs that are hard to find when porting code, updating compilers, patching compilers, changing optimisation settings, etc etc.
    vart, stahta01 and Elkvis like this.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21