0

Hi can anyone tell me would variable a remain in memory or would it get destroyed immediately.

#include <stdio.h> 

int main()
{
    {
        int a=1;
        lab:
        printf("Value of a : %d",a);  
    }   

    return 0;
}

would int a still remain in memory or not ?

Nobilis
  • 7,310
  • 1
  • 33
  • 67
Harikesh
  • 313
  • 3
  • 14
  • That depends on the actual implementation. However, its scope ended, so you can't access it anymore, and the compiler may (and most probably will) opt to use its backing memory for another variable. –  Jul 11 '13 at 13:21
  • 2
    Oh, and ***`int`*** `main()`... –  Jul 11 '13 at 13:22
  • @Mr Carbonic Acid; +google_plex. How many times do we see void main()! – Bathsheba Jul 11 '13 at 13:22
  • @Bathsheba I think half as many times as we see people casting the return value of `malloc()`. –  Jul 11 '13 at 13:23
  • @H2CO3 only old SO users are aware about it that too because of so much focus on [This](http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc) link.Still almost all the basic C books are following malloc typecasting with an excuse of portability and backward compatibility. – Dayal rai Jul 11 '13 at 13:29
  • @Dayalrai Well, I'm not an old SO user, yet I'm aware of 1. that link (I do use that myself as a weapon against whomsoever commits the crime dubbed "extraneous casting"), 2. of the fact that it should not be done (the typecast). It's unfortunate that C books do that, and it's even more unfortunate that the reasoning is "compatibility with C++" - if one has C code, it must be compiled with a C compiler. Explicitly not with a C++ one. –  Jul 11 '13 at 13:31
  • @H2CO3 `2 years, 7 months` :) and me too support your point. – Dayal rai Jul 11 '13 at 13:32
  • @Dayalrai Well, if you wish so :) But that (excellent) answer is 4 years old. –  Jul 11 '13 at 13:33

3 Answers3

3

a is destroyed (popped from the stack) when you get to the } following the line with printf , so no, it does not remain in memory at your comment line.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • I thought for sure that that's implementation-specific in C -- ie: though you can't access it by name anymore, it might still be taking up space on the stack. – cHao Jul 11 '13 at 13:29
  • It may well be in memory as it would be perfectly fine for the implementation to just move the stack cursor. You'll probably find that instantiating another int just after the brace would recover the original value intact. Relying on that is asking for trouble though. Probably UB. – Bathsheba Jul 11 '13 at 13:32
3

Nope, a has local scope (declared between brackets) so at the closing brace it will be cleaned up.

If you want it to persist for the entirety of the program, either declare it as static or put it outside of any braces, preferably before you use it.

This has the added benefit of having the compiler initialise it for you.

You can try out the following:

#include <stdio.h>
int a;

int main()
{
    static int b;

    int c;

    printf("%d, %d, %d\n", a, b, c); /* a and b should print 0, printing c is undefined behaviour, anything could be there */

    return 0;
}

As Bathsheba pointed out, static variables should be used judiciously if used in a multi-threaded environment.

Nobilis
  • 7,310
  • 1
  • 33
  • 67
1

First of all: It is not implementation specific. The C standard explicitly says, that leaving a block destroys an object with auto (local declared) lifetime:

For such an object that does not have a variable length array type, its lifetime extends from entry into the block with which it is associated until execution of that block ends in any way. [ISO/IEC9899:TC3, 6.2.4, 5]

Of course, this is hard to test, because it loses it scope, too, in this case. (The other way around is easy to test.) But this is important for a formal reason: If you have a pointer to that object, which lives longer than the object, the program is always incorrect and the behavior is undefined – even an implementation let the object being alive. (Undefnied behavior includes that everything works fine.)

Amin Negm-Awad
  • 16,582
  • 3
  • 35
  • 50
  • C's concept of "lifetime" isn't as cut-and-dried as all that. "The lifetime of an object is the portion of program execution during which storage is *guaranteed* to be reserved for it." (6.2.4, 1; emphasis mine) The end of an object's lifetime doesn't mean the space is cleaned up immediately; it just means it's no longer guaranteed by the standard to exist and only be for that object. (The implementation might have its own rules and guarantees either way, or it might not.) – cHao Jul 11 '13 at 13:46
  • Your quotation is from ISO/IEC9899:TC3? I cannot find this, but: "An object has a storage duration that determines its lifetime. There are three storage durations: static, automatic, and allocated. Allocated storage is described in 7.20.3." at 6.2.4, 1. But this does not matter: What you refer to, is that a implementation, that holds an object longer conforms to the standard. This is important to *compiler developer*. For an *application developer* the lifetime ends at the point the block is left. Even an implementation holds an object longer, for the *application programmer* is is died. … – Amin Negm-Awad Jul 11 '13 at 14:34
  • … Every C program that rely on (uses) a longer extent is an incorrect C program , even if the implementation promises to hold the object longer and even this implementation would conform to the standard. The extent is not marked as implementation-defined. – Amin Negm-Awad Jul 11 '13 at 14:38
  • My quote is copy/pasted directly from the same PDF you linked. How you didn't see it is a mystery to me, as it is literally the *very next sentence* after 6.2.4,1 (which you just pasted). The point is, the standard doesn't guarantee that the memory will be reclaimed immediately. It doesn't promise anything past that point. If the compiler makes other guarantees, then code relying on them is correct (if unportable). But code that cares about the particular movement of the stack pointer is already relying heavily on IB; the abstract machine's definition doesn't specify a stack. – cHao Jul 11 '13 at 16:34
  • You said, that you quote "(6.2.4, 1; emphasis mine)", your quotation is from 6.2.4, *2*. Probably this is the reason, that I did not see it. I looked at 6.2.4, 1. (Somebody told me to do so.) And I did not say, that the standard guarantees the immediate release of the memory. This simple irrelevant to the application developer. And no, the program is not conforming, because it relies on something, that is not flagged as implementation-defined. The phrase "not guaranteed" is used to say to the implementation programmer, that he can decide, when to free. – Amin Negm-Awad Jul 11 '13 at 17:18
  • Oops. I did mean 6.2.4,2; sorry about that. But as you've said, the entire question of whether an auto object's storage space is still reserved after its lifetime has ended is outside the scope of the standard; C does not define the behavior either way. But it can be important to the developer. While accessing the value is indeed a bad idea in any case, it's not all about the value. Sometimes your memory constraints are so tight that you need to be able to account for every byte. – cHao Jul 11 '13 at 18:49
  • Yes, this is sometimes important and it is implementation-defined. Your are completely correct about that. But this is not the behavior of the program as defined in a standard. (There are many properties of implementations that are not subject of the standard as turn-around times, runtime performance and so on. These are all important in some situation, but not standardized.) – Amin Negm-Awad Jul 11 '13 at 19:18