Thread: Bug in gcc

Originally Posted by SirPrattlepod

I have fixed the program, but it still doesn't output the right answer

Refer to post #2:

Originally Posted by Salem

You're returning a pointer to a local variable.

Refer to post #5:

Originally Posted by vart

a is uninitialized, so a += 100 is undefined

Refer to post #8:

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.

Originally Posted by SirPrattlepod

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.

Originally Posted by laserlight

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?

Originally Posted by std10093

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.

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.

Both grumpy and laserlight are correct. Thank you both!

Originally Posted by laserlight

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.