Effect of goto on local variables

[pertheli]

I am in a situation where only "goto" seems to be the answer for my
program logic where I have to retry calling some repeated functions.

Can anybody help in the usage of goto and its effect in local
variables, as shown in the stripped code below


void Process(){

int iMaxRetry = 100;
int iRetryCount = 0;
.....
.....
Retry:
iRetryCount++; // counter for retrying
somefunction1();
bool bNewBool = false; // some local variable
char* myVar1 = malloc(100);
if (!somefunction2()){ // if condition is not valid retry
if (iRetryCount < iMaxRetry){
if (myVar1) free(myVar1);
goto Retry; // go back and try again
}
}

.....
.....
}

What is the effect of calling repeated "Retry:" block to the local
variables such as bNewBool, myVar1, myVar2? Are they called again? ie
reinitialised? Is it safe to use? although it seems to be working fine

 

[Grumble]

I am in a situation where only "goto" seems to be the answer for my
program logic where I have to retry calling some repeated functions.

Can anybody help in the usage of goto and its effect in local
variables, as shown in the stripped code below


void Process(){

int iMaxRetry = 100;
int iRetryCount = 0;
....
....
Retry:
iRetryCount++; // counter for retrying
somefunction1();
bool bNewBool = false; // some local variable
char* myVar1 = malloc(100);
if (!somefunction2()){ // if condition is not valid retry
if (iRetryCount < iMaxRetry){
if (myVar1) free(myVar1);
goto Retry; // go back and try again
}
}

....
....
}

What is the effect of calling repeated "Retry:" block to the local
variables such as bNewBool, myVar1, myVar2? Are they called again? ie
reinitialised? Is it safe to use? although it seems to be working fine

Why don't you allocate memory before the loop?

Then you could write:

void Process()
{
int iRetryCount, iMaxRetry = 100;
char *myVar1 = malloc(100); /* Error-checking perhaps? */

for (iRetryCount=0; iRetryCount<iMaxRetry; ++iRetryCount)
{
somefunction1();
if ( somefunction2() ) break;
}
}

Or you could use a while loop based on condition somefunction2()
with the break inside the body, or use both tests inside the while
loop. I don't think this is an example where goto is unavoidable.

BTW, you can't declare bNewBool in the middle of your code in C.

 

[Kevin Bracey]

void Process(){

int iMaxRetry = 100;
int iRetryCount = 0;
....
....
Retry:
iRetryCount++; // counter for retrying
somefunction1();
bool bNewBool = false; // some local variable
char* myVar1 = malloc(100);
if (!somefunction2()){ // if condition is not valid retry
if (iRetryCount < iMaxRetry){
if (myVar1) free(myVar1);
goto Retry; // go back and try again
}
}

....
....
}

What is the effect of calling repeated "Retry:" block to the local
variables such as bNewBool, myVar1, myVar2? Are they called again? ie
reinitialised? Is it safe to use? although it seems to be working fine

Ignoring any issues of style, taste, decency etc, when the goto itself
happens, bNewBool and myVar1 will retain their value. When their declarations
are reached again, they will be reinitialised, and a new block of 100 will be
allocated for myVar1. Thus your code as written is basically valid (as C99 or
C++).

For what it's worth, "if (myVar1) free(myVar1);" can be simplified to
"free(myVar1);", as free() is required to accept a NULL pointer and do
nothing

 

[Ed Morton]

I am in a situation where only "goto" seems to be the answer for my
program logic where I have to retry calling some repeated functions.

I've heard some people suggest that explicit loops can sometimes be used
instead of the much more obvious backward gotos ;-).

Can anybody help in the usage of goto and its effect in local
variables, as shown in the stripped code below


void Process(){

int iMaxRetry = 100;
int iRetryCount = 0;
....
....
Retry:
iRetryCount++; // counter for retrying
somefunction1();
bool bNewBool = false; // some local variable
char* myVar1 = malloc(100);
if (!somefunction2()){ // if condition is not valid retry
if (iRetryCount < iMaxRetry){
if (myVar1) free(myVar1);
goto Retry; // go back and try again
}
}

....
....
}

<snip>

Wouldn't this be clearer:

void Process(){

int iMaxRetry = 100;
int iRetryCount = 0;
.....
.....
while (iRetryCount < iMaxRetry) {
iRetryCount++; // counter for retrying
somefunction1();
bool bNewBool = false; // some local variable
char* myVar1 = malloc(100);
if (!somefunction2()){ // if condition is not valid retry
free(myVar1);
}

.....
.....
}

I assume that you want to free(myVar1) even if you're not going to
retry, so my code above also fixes that bug. I also assume that you'll
have some code after the malloc to test for myVar1 being NULL and you
don't need to test for that before free-ing it anyway.

Ed.

 

[Scott Fluhrer]

In message <[email protected]>


Ignoring any issues of style, taste, decency etc, when the goto itself
happens, bNewBool and myVar1 will retain their value. When their declarations
are reached again, they will be reinitialised, and a new block of 100 will be
allocated for myVar1.

Actually, that is technically incorrect. The goto leaves the scope of the
bNewBool and myVar1 variables, and so the values those variables had are
forgotten. Then, after the goto, the code reenters the scope of the
bNewbool and myVar1 variables, which are then initialized in this case.

The distinction doesn't matter with the OP's code, but does in the following
case:

#include <stdio.h>
int main(void) {
int i;
for (i=0; i<2; i++) {
int value;
if (i == 0) {
value = 3;
continue;
}
printf( "%d\n", value );
}
return 0;
}

In this case, the variable value is uninitialized when the program hits the
printf, resulting in Undefined Behavior.

Thus your code as written is basically valid (as C99 or
C++).

That it is (after replacing the .... sections with valid code, of course)

 

[Kevin Bracey]

In message <[email protected]>

Actually, that is technically incorrect. The goto leaves the scope of the
bNewBool and myVar1 variables, and so the values those variables had are
forgotten.

No, that's not so. At least, assuming we're talking about C99; the issue
doesn't arise in C90, and I wouldn't know about C++ (although I'd be
surprised if it was fundementally different from C99).

There is a difference between scope and storage duration. See the heinous
example in section 6.2.4 of the C99 rationale. In the OP's example, the
goto leaves the scope of bNewBool and myVar1, but execution hasn't left
their associated block, so they still exist and retain their contents (and
could be accessed via a pointer).

 

[CBFalconer]

I am in a situation where only "goto" seems to be the answer for my
program logic where I have to retry calling some repeated functions.

Can anybody help in the usage of goto and its effect in local
variables, as shown in the stripped code below

void Process(){

int iMaxRetry = 100;
int iRetryCount = 0;
....
Retry:
iRetryCount++; // counter for retrying
somefunction1();
bool bNewBool = false; // some local variable
char* myVar1 = malloc(100);
if (!somefunction2()){ // if condition is not valid retry
if (iRetryCount < iMaxRetry){
if (myVar1) free(myVar1);
goto Retry; // go back and try again
}
}
....
}

What is the effect of calling repeated "Retry:" block to the local
variables such as bNewBool, myVar1, myVar2? Are they called again? ie
reinitialised? Is it safe to use? although it seems to be working fine

Reworked to be legitimate C and eliminate the goto. I believe the
action is identical.

Since you are using // comments you must have a C99 compiler.
However to use bool you must include stdbool.h, and to use
malloc/free you must include stdlib.h.

#include <stdbool.h>
#include <stdlib.h>
....
void Process() {
int iMaxRetry = 100;
int iRetryCount = 0;
bool bNewBool;
char *myVar1;
.....
do {
iRetryCount++;
somefunction1();
bNewBool = false;
myVar1 = malloc(100);
if (!somefunction2()) {
if (iRetryCount < iMaxRetry) {
bNewBool = true;
free(myVar1);
}
}
} while (bNewBool);
.....
}

I suggest you dispense with the silly hungarian notation. You
could probably easily wrap further actions withing somefunction2
and simplify further. Then that loop would look like:

do {
tries++
somefunction1(&MyVar1));
} while (somefunction2(tries, MyVar1));

and not strain the credulity of the average reader

 

[The Real OS/2 Guy]

I am in a situation where only "goto" seems to be the answer for my
program logic where I have to retry calling some repeated functions.

Can anybody help in the usage of goto and its effect in local
variables, as shown in the stripped code below


void Process(){

int iMaxRetry = 100;
int iRetryCount = 0;
....
....
Retry:
iRetryCount++; // counter for retrying
somefunction1();
bool bNewBool = false; // some local variable
char* myVar1 = malloc(100);
if (!somefunction2()){ // if condition is not valid retry
if (iRetryCount < iMaxRetry){
if (myVar1) free(myVar1);
goto Retry; // go back and try again
}
}

....
....
}

/* count backwards because test for 0 is more efficient than compare 2
variables */
/* use postdecrement because it saves some typing */
for (iRetrycount = iMaxRetry; iRetryCount--; ) {
/* C89 requires all declarations done befor the first statement
gets called */
bool bNewBool = FALSE;
char *myVar1 = malloc(100);
if (!myvar) continue; /* as original code tells somefuctionx needs
myvar set */
somefuction1();
if (somefunction2()) break; /* somefuction2 says 'done' */
free(myVar); /* free does nothing when called with NULL pointer
*/
}

 

[Eric Sosman]

/* count backwards because test for 0 is more efficient than compare 2
variables */
/* use postdecrement because it saves some typing */
for (iRetrycount = iMaxRetry; iRetryCount--; ) {

Oh, good grief! One could equally well argue that counting
forward is better because clearing the counter to zero is "more
efficient" than initializing it to a non-zero value. Without
some idea of how many times the loop will be executed, it's not
possible to say which effect will dominate.

And either way, the savings -- if any -- will be trivial,
as in too small to measure.

A friend of mine used to refer to this sort of optimization
as "Cleaning the bottle caps off the beach so the sand will be
nice and smooth around the whale carcasses."