Hi all,

I am a newbie in C, and a bit curious with this "goto" statement.

For instance, I create a simple code below

#include <stdio.h>

int main ()
 {

int a;
a = 1+1;

if (a!=2)
{ 
goto error;
}

error:
printf("error is here\n");
return 0;

}

it still prints me the printf function, although the condition is not satisfied.
I can avoid this by creating an else goto noterror. But what if I need a lot of goto, does it mean I need to also create a gotonoterror (under else) for each part?
why does it keeps going to goto, although the condition is not satisfied for the above code? any other way to avoid this?

Thank you

Dani AI

Generated

As several replies already explain (notably , and ), a label like error: is only a marker for a position in the code, not an executable statement. If normal control flow reaches that position (fall‑through after an if), the labeled statement will run whether or not any goto was taken. The original program prints because execution simply reaches the error: label after the if completes.

Common, clearer idioms for “run this only on error”:

  • Early return on success so the error label is never reached (shown earlier by ).
  • Use a cleanup label for resource teardown when multiple failure points exist — this keeps the happy path simple and avoids deeply nested ifs. Example cleanup pattern:
#include <stdio.h>
#include <stdlib.h>

int do_work(void) {
    FILE *f = NULL;
    char *buf = NULL;
    int rc = -1;

    buf = malloc(128);
    if (!buf) goto cleanup;

    f = fopen("data.txt", "r");
    if (!f) goto cleanup;

    /* normal processing */
    rc = 0; /* success */

cleanup:
    if (f) fclose(f);
    free(buf);
    return rc;
}

int main(void) { return do_work(); }
  • Another structured alternative is a single‑iteration loop with break for early exits (avoids goto entirely):
do {
    if (a != 2) { printf("error\n"); break; }
    printf("all good\n");
} while (0);

Rule of thumb: prefer structured control (if/else, early returns, helper functions). Reserve goto for a small set of well‑scoped uses such as centralized cleanup when it measurably improves readability. This resolves the confusion shown in ’s example: the label itself does not run because of the if — it runs because normal flow reaches it.

Recommended Answers

All 8 Replies

The goto allows you to jump to a tagged location in your code. If you set up a tag ( error: in your case) then goto error; moves execution directly to that location. Nothing prevents that location from being in some other execution path as well.

If you've got some conditional execution path that you'd like to add use the if (condition) construct to control that: place the code within the scope of the if statement. There are limited instances where goto can not be replaced by some other logic. It is best to avoid goto in general until you come across one of these instances.

The goto allows you to jump to a tagged location in your code. If you set up a tag ( error: in your case) then goto error; moves execution directly to that location. Nothing prevents that location from being in some other execution path as well.

If you've got some conditional execution path that you'd like to add use the if (condition) construct to control that: place the code within the scope of the if statement. There are limited instances where goto can not be replaced by some other logic. It is best to avoid goto in general until you come across one of these instances.

yes, I understand that.
but I am still unclear about the if condition, as in my code, I put the goto under if condition (if a!=2, print error).
However, the goto statement is still executed, although it contradict the if statement. As what I understand from your explanation, I am doing the right thing (or?)

Thank you..

However, the goto statement is still executed

The goto statement didn't execute. It only seems that way because your labeled statement is in both execution paths. Consider this:

#include <stdio.h>

int main()
{
    int a;
    
    a = 1+1;

    /*
    if (a!=2) {
        goto error;
    }
    */

error:
    printf("error is here\n");
    return 0;
}

You'll get the same output even though the if statement is removed entirely. The label doesn't change the flow of execution at all.

after the execution of statement "if(a!=2)" condition is false, then the control will move to "error:" irrespective of whether it is true or not.

yes...i agree with narue...

check this

#include <stdio.h>
 
int main()
{
    int a;
 
    a = 1+1;
 
    
    if (a!=2) {
printf("abcde");    
    goto error;
    }
    
 
error:
    printf("error is here\n");
    return 0;
}

first printf statement will never execute

yes...i agree with narue...

first printf statement will never execute

Ah yes, you are correct. But I am still confused with this. So the case is that, the label will be executed, whatever happens. I mean, the if function does not have an effect at all.

So how am I supposed to execute the label, in under a certain condition, if the program will execute it anyways, despite the condition?

Thank you..

So the case is that, the label will be executed, whatever happens.

The label isn't an executable statement, it's only a tag for some position within the execution path.

So how am I supposed to execute the label, in under a certain condition, if the program will execute it anyways, despite the condition?

In the case of error paths and goto, it's usually done like this:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    int x;
    
    printf("Enter a number [0, 10): ");
    fflush(stdout);
    
    if (scanf("%d", &x) != 1 || !(x >= 0 && x < 10))
        goto error;
        
    printf("%d squared is %d\n", x, x * x);
    
    /* Do something to avoid executing the error path */
    return EXIT_SUCCESS;
    
error:
    /* Define a separate execution path for the goto */
    printf("Invalid input\n");
    return EXIT_FAILURE;
}

AH ! That explains! THANK YOU!!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.