About regaining the memory associated with a block-specific variable and reusing it further.

NOTE : I am using the terms "reuse" or "reusable" with respect to the object code generated at the compilation time. /* * Program to analyze whether it is meaningful to reuse the * stack memory once the respective variable goes out of * scope. */ #include<stdio.h> int main() { int a; /* Let's say this has the address : A. */ printf("\n &a = %p ", &a); { int b; /* Let's say this has the address : B. */ printf("\n &b = %p", &b); } int c; /* Let's say this has the address : C. */ printf("\n &c = %p", &c); return 0; } Win32 O/P: &a = 0022FF74 &b = 0022FF70 &c = 0022FF6C Fedora Core Linux O/P: &a = 0xbfaec044 &b = 0xbfaec040 &c = 0xbfaec03c Here, I think that C could be same as B since the respective memory becomes reusable once the variable 'b' goes out of scope, But, the behavior of this program differs from what I think as above when tested on platforms - Windows XP and Fedora Core Linux with GCC versions 3.4.2 (Thread model - win32) and 3.4.6 (Thread model - posix) respectively. This behavior looks like being closely related to the implementation of the compiler in deciding the memory utilization for the local variables. However, it would be interesting to know whether are there any restrictions imposed by Standard C(C99) in doing so(reuse) as far as the language "C" is concerned. Cheers.

Myth__Buster <raghavanil4m@gmail.com> writes: > NOTE : I am using the terms "reuse" or "reusable" with respect to > the object code generated at the compilation time. > > /* > * Program to analyze whether it is meaningful to reuse the > * stack memory once the respective variable goes out of > * scope. > */ > > #include<stdio.h> > > int main() > { > int a; /* Let's say this has the address : A. */ > printf("\n &a = %p ", &a); Technically, you should say printf("\n &a = %p ", (void *)&a); here. > { > int b; /* Let's say this has the address : B. */ > printf("\n &b = %p", &b); > } > > int c; /* Let's say this has the address : C. */ > printf("\n &c = %p", &c); > > return 0; > } > > Win32 O/P: > &a = 0022FF74 > &b = 0022FF70 > &c = 0022FF6C > > Fedora Core Linux O/P: > &a = 0xbfaec044 > &b = 0xbfaec040 > &c = 0xbfaec03c > > Here, I think that C could be same as B since the respective memory > becomes reusable once the variable 'b' goes out of scope, But, the > behavior of this program differs from what I think as above when > tested > on platforms - Windows XP and Fedora Core Linux with GCC versions > 3.4.2 (Thread model - win32) and 3.4.6 (Thread model - posix) > respectively. > > This behavior looks like being closely related to the implementation > of the compiler in deciding the memory utilization for the local > variables. Yes, it is. > However, it would be interesting to know whether are > there any restrictions imposed by Standard C(C99) in doing so(reuse) > as > far as the language "C" is concerned. The main one is that an object has a constant address throughout its lifetime. Combine this with the fact that addresses compare equal when they refer to the same object and you will have most of the rules you need. The compiler can always break C's rules if the program can't tell the difference. For example, a, b and c could be allocated at the same location (or even not at all) if you did not take the address of any of them and the usage permitted such re-use. I don't think gcc spends much time trying to reduce the space used by local objects so you are unlikely to see this in practise. -- Ben.

On Feb 1, 6:15=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: > Myth__Buster <raghavani...@gmail.com> writes: > > NOTE : I am using the terms "reuse" or "reusable" with respect to > > the object code generated at the compilation time. > > > /* > > =A0* =A0 =A0Program to analyze whether it is meaningful to reuse the > > =A0* =A0 =A0stack memory once the respective variable goes out of > > =A0* =A0 =A0scope. > > =A0*/ > > > #include<stdio.h> > > > int main() > > { > > =A0 =A0int a; =A0/* Let's say this has the address : A. */ > > =A0 =A0printf("\n &a =3D %p ", &a); > > Technically, you should say printf("\n &a =3D %p ", (void *)&a); here. > > > > > > > > > > > =A0 =A0{ > > =A0 =A0 =A0 =A0 =A0 =A0int b; /* Let's say this has the address : B. */ > > =A0 =A0 =A0 =A0 =A0 =A0printf("\n &b =3D %p", &b); > > =A0 =A0} > > > =A0 =A0int c; /* Let's say this has the address : C. */ > > =A0 =A0printf("\n &c =3D %p", &c); > > > =A0 =A0return 0; > > } > > > Win32 O/P: > > &a =3D 0022FF74 > > &b =3D 0022FF70 > > &c =3D 0022FF6C > > > Fedora Core Linux O/P: > > &a =3D 0xbfaec044 > > &b =3D 0xbfaec040 > > &c =3D 0xbfaec03c > > > Here, I think that C could be same as B since the respective memory > > becomes reusable once the variable 'b' goes out of scope, But, the > > behavior of this program differs from what I think as above when > > tested > > on platforms - Windows XP and Fedora Core Linux with GCC versions > > 3.4.2 (Thread model - win32) and 3.4.6 (Thread model - posix) > > respectively. > > > This behavior looks like being closely related to the implementation > > of the compiler in deciding the memory utilization for the local > > variables. > > Yes, it is. > > > However, it would be interesting to know whether are > > there any restrictions imposed by Standard C(C99) in doing so(reuse) > > as > > far as the language "C" is concerned. > > The main one is that an object has a constant address throughout its > lifetime. =A0Combine this with the fact that addresses compare equal when > they refer to the same object and you will have most of the rules you > need. > > The compiler can always break C's rules if the program can't tell the > difference. =A0For example, a, b and c could be allocated at the same > location (or even not at all) if you did not take the address of any of > them and the usage permitted such re-use. =A0I don't think gcc spends muc= h > time trying to reduce the space used by local objects so you are > unlikely to see this in practise. > > -- > Ben. Okay. Actually, my idea was to optimize the stack usage by the local arrays of reasonable sizes specific to blocks.

Myth__Buster <raghavanil4m@gmail.com> writes: <snip> > Okay. Actually, my idea was to optimize the stack usage by the local > arrays > of reasonable sizes specific to blocks. In that case, if the arrays are not variably modified, you could put those that can be reused into a union. If they are of the same element type, you could even dispense with the union, but it helps to keep the naming clear. Your example with single ints would then be: int a; /* ... */ union { int b, c; } b_or_c; { /* use b_or_c.b here */ } /* use b_or_c.c here */ If the arrays are variably modified and of different types, then I am not sure what the best strategy might be. I think it would depend on exactly what you are doing. -- Ben.

Myth__Buster <raghavanil4m@gmail.com> writes: > NOTE : I am using the terms "reuse" or "reusable" with respect to > the object code generated at the compilation time. > > /* > * Program to analyze whether it is meaningful to reuse the > * stack memory once the respective variable goes out of > * scope. > */ > > #include<stdio.h> > > int main() > { > int a; /* Let's say this has the address : A. */ > printf("\n &a = %p ", &a); > > { > int b; /* Let's say this has the address : B. */ > printf("\n &b = %p", &b); > } > > int c; /* Let's say this has the address : C. */ > printf("\n &c = %p", &c); > > return 0; > } The lifetimes of both a and c cover the entire block that encloses their declarations. The lifetime of b covers the inner block in which it's declared. Thus b and c have overlapping lifetimes, and cannot (in the abstract machine) share the same address. You might think that the lifetime of c starts at its declaration, but C99 6.2.4p5 says otherwise; it exists starting on entry to the block, but its value is indeterminate until its declaration is reached. It's possible to contrive a program that stores the address of c in an int* variable, then uses goto to branch to a point before its declaration; that code can access the object "before" its declaration. If you hadn't displayed the addresses of the objects, the compiler could store them in the same location, as long as the program's visible behavior isn't affected by the optimization. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Feb 1, 8:17=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: > Myth__Buster <raghavani...@gmail.com> writes: > > <snip> > > > Okay. Actually, my idea was to optimize the stack usage by the local > > arrays > > of reasonable sizes specific to blocks. > > In that case, if the arrays are not variably modified, you could put > those that can be reused into a union. =A0If they are of the same element > type, you could even dispense with the union, but it helps to keep the > naming clear. > > Your example with single ints would then be: > > =A0 int a; > =A0 /* ... */ > =A0 union { int b, c; } b_or_c; > =A0 { > =A0 =A0 =A0 /* use b_or_c.b here */ > =A0 } > =A0 /* use b_or_c.c here */ > > If the arrays are variably modified and of different types, then I am > not sure what the best strategy might be. =A0I think it would depend on > exactly what you are doing. > > -- > Ben. Yes. Nice to see the other possibility. But, I just tried my hands on the approach where the compiler does the job for you instead as I said earlier. And I agree that if it were VLAs it might need some more tweaking before one can zero in on the suitable strategy herein.

On 2011-02-01, Myth__Buster <raghavanil4m@gmail.com> wrote: > However, it would be interesting to know whether are > there any restrictions imposed by Standard C(C99) in doing so(reuse) > as > far as the language "C" is concerned. None, it's all undefined behavior. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.

On 2011-02-01, Myth__Buster <raghavanil4m@gmail.com> wrote: > Okay. Actually, my idea was to optimize the stack usage by the local > arrays > of reasonable sizes specific to blocks. This is unlikely to yield a good return on your time. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.

On Feb 1, 8:30=A0am, Keith Thompson <ks...@mib.org> wrote: > Myth__Buster <raghavani...@gmail.com> writes: > > NOTE : I am using the terms "reuse" or "reusable" with respect to > > the object code generated at the compilation time. > > > /* > > =A0* =A0 =A0Program to analyze whether it is meaningful to reuse the > > =A0* =A0 =A0stack memory once the respective variable goes out of > > =A0* =A0 =A0scope. > > =A0*/ > > > #include<stdio.h> > > > int main() > > { > > =A0 =A0int a; =A0/* Let's say this has the address : A. */ > > =A0 =A0printf("\n &a =3D %p ", &a); > > > =A0 =A0{ > > =A0 =A0 =A0 =A0 =A0 =A0int b; /* Let's say this has the address : B. */ > > =A0 =A0 =A0 =A0 =A0 =A0printf("\n &b =3D %p", &b); > > =A0 =A0} > > > =A0 =A0int c; /* Let's say this has the address : C. */ > > =A0 =A0printf("\n &c =3D %p", &c); > > > =A0 =A0return 0; > > } > > The lifetimes of both a and c cover the entire block that encloses > their declarations. =A0The lifetime of b covers the inner block in > which it's declared. =A0Thus b and c have overlapping lifetimes, > and cannot (in the abstract machine) share the same address. If this turns out to be the case, I could see that some stack space being eaten up by the variables yet unused in the outermost block. Well, this could be an inefficient object code generation as well right? The inefficiency here I am referring is in terms of memory space consumption. Having said that, I could see no other sort of manipulations to avoid this compile-time inefficiency in case the control doesn't reach the yet unused variables as mentioned above. If there are, then I would be eager to know them. > > You might think that the lifetime of c starts at its declaration, > but C99 6.2.4p5 says otherwise; it exists starting on entry to > the block, but its value is indeterminate until its declaration > is reached. =A0It's possible to contrive a program that stores the > address of c in an int* variable, then uses goto to branch to > a point before its declaration; that code can access the object > "before" its declaration. > Yes, I agree on this - bad coding practice but interesting possibility as well.. > If you hadn't displayed the addresses of the objects, the compiler > could store them in the same location, as long as the program's > visible behavior isn't affected by the optimization. > Yes, that seems feasible. I tried with the same win32 GCC and printed the addresses of b and C through GDB. Unless I try to print their addresses, they are having the same addresses - tried assigning a value to it, etc. So, that's a good finding for me.. Thanks. > -- > Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net/~= kst> > Nokia > "We must do something. =A0This is something. =A0Therefore, we must do thi= s." > =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Myth__Buster <raghavanil4m@gmail.com> writes: > <snip> >> Okay. Actually, my idea was to optimize the stack usage by the local >> arrays >> of reasonable sizes specific to blocks. > > In that case, if the arrays are not variably modified, you could put > those that can be reused into a union. If they are of the same element > type, you could even dispense with the union, but it helps to keep the > naming clear. > > Your example with single ints would then be: > > int a; > /* ... */ > union { int b, c; } b_or_c; > { > /* use b_or_c.b here */ > } > /* use b_or_c.c here */ > > If the arrays are variably modified and of different types, then I am > not sure what the best strategy might be. I think it would depend on > exactly what you are doing. Hmm. That strikes me as excessive micro-optimization, especially since (in this case) all it saves you is the storage for a single int. And b_or_c might as well be an int rather than a union. Crank up the optimization level on your compiler, *don't* take the address of the variables in your code, and take a look at the generated assembly to see if it manages to reuse the same memory (or, perhaps more likely, just keep the values in registers). Or, if you haven't demonstrated a real need to save storage, consider not worrying about it. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"

Seebs <usenet-nospam@seebs.net> writes: > On 2011-02-01, Myth__Buster <raghavanil4m@gmail.com> wrote: >> However, it would be interesting to know whether are >> there any restrictions imposed by Standard C(C99) in doing so(reuse) >> as >> far as the language "C" is concerned. > > None, it's all undefined behavior. What behavior is undefined? It's up to the implementation to decide whether to use the same storage for different objects (but only if doing so doesn't change the behavior of the program). But I see nothing undefined about the behavior of the original program. Plenty of unspecified and/or implementation-defined behavior (such as the output produced by "%p"), but nothing undefined. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2011-02-01, Keith Thompson <kst-u@mib.org> wrote: > What behavior is undefined? > It's up to the implementation to decide whether to use the same > storage for different objects (but only if doing so doesn't change > the behavior of the program). But I see nothing undefined about > the behavior of the original program. Plenty of unspecified and/or > implementation-defined behavior (such as the output produced by > "%p"), but nothing undefined. Right you are. I misinterpreted the OP to be asking about reusing objects after they'd been deallocated -- say, returning pointers to local variables and using them after they've gone out of scope. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.

Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Myth__Buster <raghavanil4m@gmail.com> writes: >> <snip> >>> Okay. Actually, my idea was to optimize the stack usage by the local >>> arrays >>> of reasonable sizes specific to blocks. >> >> In that case, if the arrays are not variably modified, you could put >> those that can be reused into a union. If they are of the same element >> type, you could even dispense with the union, but it helps to keep the >> naming clear. >> >> Your example with single ints would then be: >> >> int a; >> /* ... */ >> union { int b, c; } b_or_c; >> { >> /* use b_or_c.b here */ >> } >> /* use b_or_c.c here */ >> >> If the arrays are variably modified and of different types, then I am >> not sure what the best strategy might be. I think it would depend on >> exactly what you are doing. > > Hmm. That strikes me as excessive micro-optimization, especially > since (in this case) all it saves you is the storage for a single > int. The OP said it was for arrays. I am not sure if it is worth it even then, but I didn't want to make up a new example so I just illustrated the idea with the OP's example which had stand-alone ints. <snip> -- Ben.

This is really up to the compiler. There is no requirement for a nested scope's variable space to be made available after the scope is closed. Related matter: I remember some years back noticing that for code like void foo() { a(1); b(2); c(3); } gcc results would left the 1 and the 2 on the stack until after the call to c was complete, presumably to eliminate the two extra stack chopping instructions. I don't know if it would still do this today.

On Feb 1, 12:14=A0pm, Myth__Buster <raghavani...@gmail.com> wrote: > On Feb 1, 8:30=A0am, Keith Thompson <ks...@mib.org> wrote: > > > > > > > Myth__Buster <raghavani...@gmail.com> writes: > > > NOTE : I am using the terms "reuse" or "reusable" with respect to > > > the object code generated at the compilation time. > > > > /* > > > =A0* =A0 =A0Program to analyze whether it is meaningful to reuse the > > > =A0* =A0 =A0stack memory once the respective variable goes out of > > > =A0* =A0 =A0scope. > > > =A0*/ > > > > #include<stdio.h> > > > > int main() > > > { > > > =A0 =A0int a; =A0/* Let's say this has the address : A. */ > > > =A0 =A0printf("\n &a =3D %p ", &a); > > > > =A0 =A0{ > > > =A0 =A0 =A0 =A0 =A0 =A0int b; /* Let's say this has the address : B. = */ > > > =A0 =A0 =A0 =A0 =A0 =A0printf("\n &b =3D %p", &b); > > > =A0 =A0} > > > > =A0 =A0int c; /* Let's say this has the address : C. */ > > > =A0 =A0printf("\n &c =3D %p", &c); > > > > =A0 =A0return 0; > > > } > > > The lifetimes of both a and c cover the entire block that encloses > > their declarations. =A0The lifetime of b covers the inner block in > > which it's declared. =A0Thus b and c have overlapping lifetimes, > > and cannot (in the abstract machine) share the same address. > > If this turns out to be the case, I could see that some stack space > being eaten up by the variables yet unused in the outermost block. > Well, this could be an inefficient object code generation as well > right? The inefficiency here I am referring is in terms of memory > space consumption. > > Having said that, I could see no other sort of manipulations to avoid > this compile-time inefficiency in case the control doesn't reach the > yet > unused variables as mentioned above. If there are, then I would be > eager to know them. Why not enclose the parts that use a and c in their own blocks?

On Feb 2, 1:57=A0am, "robertwess...@yahoo.com" <robertwess...@yahoo.com> wrote: > On Feb 1, 12:14=A0pm, Myth__Buster <raghavani...@gmail.com> wrote: > > > > > On Feb 1, 8:30=A0am, Keith Thompson <ks...@mib.org> wrote: > > > > Myth__Buster <raghavani...@gmail.com> writes: > > > > NOTE : I am using the terms "reuse" or "reusable" with respect to > > > > the object code generated at the compilation time. > > > > > /* > > > > =A0* =A0 =A0Program to analyze whether it is meaningful to reuse th= e > > > > =A0* =A0 =A0stack memory once the respective variable goes out of > > > > =A0* =A0 =A0scope. > > > > =A0*/ > > > > > #include<stdio.h> > > > > > int main() > > > > { > > > > =A0 =A0int a; =A0/* Let's say this has the address : A. */ > > > > =A0 =A0printf("\n &a =3D %p ", &a); > > > > > =A0 =A0{ > > > > =A0 =A0 =A0 =A0 =A0 =A0int b; /* Let's say this has the address : B= .. */ > > > > =A0 =A0 =A0 =A0 =A0 =A0printf("\n &b =3D %p", &b); > > > > =A0 =A0} > > > > > =A0 =A0int c; /* Let's say this has the address : C. */ > > > > =A0 =A0printf("\n &c =3D %p", &c); > > > > > =A0 =A0return 0; > > > > } > > > > The lifetimes of both a and c cover the entire block that encloses > > > their declarations. =A0The lifetime of b covers the inner block in > > > which it's declared. =A0Thus b and c have overlapping lifetimes, > > > and cannot (in the abstract machine) share the same address. > > > If this turns out to be the case, I could see that some stack space > > being eaten up by the variables yet unused in the outermost block. > > Well, this could be an inefficient object code generation as well > > right? The inefficiency here I am referring is in terms of memory > > space consumption. > > > Having said that, I could see no other sort of manipulations to avoid > > this compile-time inefficiency in case the control doesn't reach the > > yet > > unused variables as mentioned above. If there are, then I would be > > eager to know them. > > Why not enclose the parts that use a and c in their own blocks? Yes, that sounds good. So, I tried it with the below example on both win32 and Fedora core Linux platforms with the same gcc and gdb versions used earlier. int main() { { int a =3D 1; } { int b =3D 1; } { int c =3D 1; } return 0; } The addresses seen through GDB was same for all the variables under both win32 and Linux platforms. Based on these observations and the inputs from the people here, I am getting the feeling that it is really up to the compiler to reuse the memory specific to block variables for the subsequent variables. So, this flexibility doesn't appear as a portable one. The only difference though not relevant to the present question was that when an attempt was made to print the addresses of all the variables after putting the breakpoint at main and running it, under win32 it succeeded in displaying the addresses whereas under Linux, it was not the case. Under Linux, when I tried the same way of debugging, unless the control reached the variable's definition, the respective symbol information wasn't available and hence was unable to print the variables' addresses in advance at the very entry point of main. I said the above observation is irrelevant here since I think the above is something to do with the debugging information populated by the gcc when used with option 'g'. Isn't it?